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Preface  to  the  Preliminary  Draft 


This  document  is  a Preliminary  Draft  of  th''  Formal  Definition  of  the  Green 
Programming  Language.  <vs  such,  it  indicates  the  structure  end  style  of  the 
final  document.  A»t  this  stage,  the  *v  t » t i e ^~m?nt  1 cs  is  veil  advanced  but  not 
O complete,  end  large  parts  of  the  Pyn  ^ i c c.  r.n.-n  t ? cs  are  missing.  Some  sections 

(such  as  Chapter  4 - 6)  hove  been  worked  on  in  detail  to  give  a better  idea  of 
the  final  shape  of  the  Formal  Definition. 
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1.  Introduction  and  Overview 
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1.1  Introduction 


As  a part  of  the  DOD-1  language  effort,  the  Steelman  Report  requires  a formal 
dof ini t ion  (1H)  . This  requirement  is  innovative  and  far-sighted. 


Purposes 

A formal  definition  can  be  put  to  good  use: 

(i)  As  a standard  for  the  language,  that  is  as  a means  to  answer  unambiguously 
all  questions  that  a programmer  or  an  implementor  may  raise  about  th* 
meaning  of  a construct  of  the  language.  The  formal  definition  should  serve 
as  a reference  document  for  the  validation  of  implementations  and  as  r 
guideline  for  implementors . I t should  unify  the  user  interfere  across 
implementations  (e.g.  error  messages)  and  the  interface  between  processors 
manipulating  programs  (e.g.  mechanical  aids  for  normal izntion  and 
documentation  of  Green  programs  ) . 

(ii)  As  a reference  document  for  justifying  the  val id i ty  of  optimizations  and 
other  program  transformations.  The  only  vaiio  optimisations  will  be  those 
that  do  not  alter  the  meaning  of  a program. 

(iii) As  a reference  document  for  proving  properties  of  programs  written  in  the 
language.  In  particular,  it  will  allow  the  derivation  of  inference  rules 
that  can  be  used  conveniently  when  proving  properties  of  programs. 

(iv)  As  an  input  for  a compiler-generator  when  the  technology  becomes  available. 
The  Formal  Definition  given  in  this  report  is  specified  with  enough 
precision  to  be  processed,  except  for  some  straightforward  notational 
transformations,  by  the  experimental  system  SIS  (Mosses). 

Furthermore,  the  concurrent  development  of  Green  and  its  formal  definition  has 

already  resulted  in  further  major  benefits: 

- Difficulties  in  early  drafts  of  the  Reference  Manual  (such  as  lack  of 
clarity,  ambiguities,  omissions  or  inconsistencies)  were  uncovered  very 
early. 

Feedback  was  established  to  strive  for  economy  of  concepts  in  the  Green 
language. 
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When  designing  the  formal  definition  of  a language  like  Green,  there  are  two 
major  requirements  to  satisfy: 

(i)  The  definition  should  be  complete . If  the  definition  i «;  not  complete  Jt-g 
usefulness  as  a reference  will  be  seriously  diminished.  This  completeness 
can  only  be  achieved  by  using  a mathematically  well-founded  definitional 
method. 

As  of  the  Spring  of  1979,  however,  the  State  of  the  Art  in  formal  semantics 
does  not  allow  us  to  offer  o mathematically  meaningful  semantics  for 
parallel  ism.  This  is  a very  serious  gap  in  our  theoretical  understanding 
of  programs.  No  attempt  has  been  made  here  to  give  a dynamic  semantics  for 
task  synchronisation  in  Green,  while  it  is  hoped  that  all  other  aspects  of 
the  language  are  satisfactorily  covered. 

In  all  matters  relating  to  concurrency,  the  readers  will  have  to  do  with 
the  textual  description  of  the  dynamic  semantics  that  is  provided,  pending 
a scientific  breakthrough. 

(ii) .  The  Formal  Definition  of  Green  is  meant  to  be  used  in  an  industr i ?1 

environment.  It  must  not  remain  an  academic  exercise.  One  difficulty  when 
trying  to  reach  a wider  audience  is  the  notaticnal  barrier. 

A great  deal  of  effort  should  be  spent  on  the  style  of  the  definition  and  its 
intuitive  content,  to  make  it  accessible  to  the  intend''  readership: 
implementors-  of  compilers,  standardisat ion  committees,  educated  Green 
programmers.  Naturally,  such  an  attempt  should  preserve  the  mathematical  r Igor 
of  the  definition,  and  should  be  seen  merely  as  the  development  of  a convenient 
notation. 

The  formal  definition  given  here  is  akin  to  a large  program.  Special  attention 
has  been  given  to  several  key  issues: 

- The  structure  of  the  description  reflects  the  underlying  semantic  concepts 
of  the  language. 

- The  choice  of  identifiers  3teys  as  close  as  possible  to  the  terminology  of 
the  Reference  Manual. 

- The  style  of  the  description  is  homogeneous  and  uniform  conventions  are 
used  throughout. 

Method 


There  are  three  widely  accepted  methods  of  formally  defining  the  semantics  of  a 
programming  language. 

(a)  Operational  Semantics 

In  this  method,  best  exemplified  by  the  Vienna  Definition  Method,  the  semantics 
is  modelled  by  the  behavior  of  an  abstract  machine.  Thl3  has  a practical  appeal 
but  also  presents  several  problems: 
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(i)  The  mechanism  of  the  abstract  machine  tends  to  overspecify  the  language 
since  all  details  of  machine-state  transitions  must  be  given. 

(ii)  Tt  is  not  immediately  obvious  that  the  language  has  been  well  defined.  One 
must  rely  on  a proof  that  any  execution  terminates  with  a unique  answer. 

(iii) The  theory  of  operational  semantics  is,  in  fact,  rather  difficult  and  not 
well-understood.  Using  on  operational  semantics  to  validate  optimizations 
or  to  prove  properties  of  programs  is  intricate  because  w«  -tp  not 
well-couippec?  to  reason  logically  about  the  behavior  of  a complex  machine. 

(b)  Axiomatic  Definition 

O 

This  method  is  very  popular  because  it  is  directed  towards  proving  properties  of 
programs.  Its  deficiencies,  however,  render  it  totally  unsuitable  for  the 
O definition  of  a language  like  Green: 

(i)  First,  giving  some  properties  of  language  constructs  cannot  constitute  a 

s O definition,  unless  some  proof  of  completeness  can  be  given. 

(ii)  An  axiomatic  definition  is  not  adapted  to  a use  by  implementors  since  many 

O details  about  the  dynamic  semantics  cannot  be  formalized  edeouately. 

(iii) No  complete  axic^atic  definition  of  a large  programming  language  has  ever 

O been  carried  out  successfully,  to ’ date.  Treatment  of  exceptions,  for 

example,  does  not  fit  well  in  this  formalism.  It  is  even  doubtful  that 
this  method  can  accomodate  it  at  all. 

i o 

(c)  Dcr.otat  tonal  Semantics 

' O In  this  document,  we  are  going  to  present  a formal  definition  of  Green  using 

denotetional  semantics.  There  are  several  reasons  for  choosing  this  method: 

| O (t)  It  allows  the  definition  of  the  language  to  any  desired  level  of  detail. 

(ii)  The  method  has  been  used  (with  success)  on  a number  of  languages  with 
O characteristics  similar  to  those  of  Green:  Pascal,  Algol  60,  CLU,  etc. 

(iil)The  mathematics  underlying  this  method  have  been  extensively  investigated. 
O The  method  is  based  on  very  strong  theoretical  foundations. 

(iv)  It  is  well-suited  to  proving  the  validity  of  program  transformations  and 

; O proving  properties  of  programs. 

A potential  objection  to  the  use  of  this  method  is  the  arcane  style  of 
vJ  presentation  traditionally  favored  by  its  advocates.  In  this  report,  we  hope  to 

have  overcome  this  difficulty. 

Summary  of  Denote*  tonal  Scmant ics 

In  denotetional  semantics,  one  wishes  to  associate  to  '■'very  program  an  abstract 
mathematical  object  called  its  meaning . Usually,  thn  mining  of  a program,  is 
some  functional  object,  say  a function  from  inputs  to  outputs.  The  mapnino  that 
specifies  how  one  associates  a moaning  to  every  program  in  Green  is  cal  led  the 
denotnt tonal  semantics  of  Green.  To  prooorly  define  the  denotetional  semantics 
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of  a language,  one  must  first  define  a semantic  universe,  where  meanings  rrr  to 
be  found.  Then  one  describes  how  to  associate  a meaning  to  ev«ry  atomic 
component  of  a program  end,  for  every  construct  of  the  language,  how  to  derive 
the  meaning  of  a compound  fragment  of  program  from  the  meaning  .of  its  subpa-ts. 
Hence,  denotational  semantics  is  nothing  but  a rather  l^rqe,  recursive 
definition  of  a function  from  syntactic  objects  - programs  - to  semantic  objects 
- input-output  functions. 

Defining  the  semantics  of  a language  in  this  way  naturally  leads  to  a3signinn  a 
moaning  not  only  to  complete  programs  but  also  to  program  fragments,  a very 
useful  mathematical  property  known  as  referential  transparency.  The  recursive 
structure  of  the  syntactic  objects  is  well  captured  by  the  ebr t r vt  ryn^-x  of 
Green.  Section  1.2  is  devoted  to  a detailed  presentation  of  th"  abstract  syntax 
of  Green,  that  is  of  the  tree  form  of  Green  programs. 

There  is  a wide  body  of  literature  discussing  the  mathematical  nature  of  thn 
semantic  domains  that,  need  to  be  used.  At  first,  it  is  not  necessary  to 
understand  in  depth  the  mathematical  theory  of  those  domains  in  order  to  follow 
the  semantic  description  of  Green.  Drnotat i on*l  semantics  use?  a vary  small 
number  of  concepts.  Wc  shall  describe,  in  general  terms,  thr^e  k~ys  ideas  that 
pervade  the  whole  definition. 

Green  is  an  imperative  language.  Understanding  it  requires  some  notier  of  a 
store . Programs  use  the  store  and  update  it  as  they  are  executed.  Now  if  w? 
wish  to  describe  th"  store  as  abstractly  as  possible,  that  is  without  assuming 
any  particular  implementation,  all  wc  need  to  know  is  that  it.  defines  ? mapping 

STORE ; LOCATIONS  > VALUES 

If  s is  a store  and  1 is  a location  the  expression  s(l)  will  then  denote  the 
value  stored  at  ‘location  1.  To  update  the  store,  we  will  assume  the  existence 
of  a function  UPDATE  that,  given  a store  s,  a location  1 ard  a value  v returns  a 
new  store  s’  ■ UPDATE (s, 1 ,v)  that  differs  from  s only  by  the  fact  that  s’  (1)  * 
v.  Typically,  it  is  the  purpose  of  an  assignment  statement  to  modify  the  store. 

Another  feature  of  Green  is  its  block  structure.  This  feature  allows  a given 
identifier  to  refer  to  different  objects,  depending  on  where  it  occurs  in  a 
program.  To  model  this  phenomenon  abstractly,  we  will  assume  the  existence  of  a 
mapping : 

ENVIRONMENT;  IDENTIFIERS  > DENOTATIONS 

Here  again,  by  merely  saying  that  an  environment  is  such  a mapping,  we  want  to 
avoid  describing  any  particular  implementation  of  this  concept.  The  primary 
purpose  of  declarations  is  to  modify  the  environment.  In  Green,  however,  there 
are  many  other  ways  to  alter  the  environment. 

As  a third  example,  let  us  consider  the  problem  of  describing  the  control 
mechanism  of  Green.  At  first  it  would  not  seem  too  easy  to  describe  it  in  a 
refcrcntially  transparent  manner.  If  the  meaning  of  an  assignment  is  come 
transformation  of  the  store,  the  meaning  of  a seeuencc  of  assignments  should  be 
the  composition  of  these  transformations.  3ut  what  if  we  wish  to  give  meaning 
to  a goto  statement  or  an  exit  statement?  How  can  we  describe  the  raising  of  an 
exception,  either  explicitly  or  during  the  evaluation  of  an  expression?  A very 
general  technique  allows  us  to  deal  with  this  kind  of  problem  in  denotations] 
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semantics.  Intuitively,  the  idee  here  is  to  give  to  the  semantic  functions  on 
extra  pedometer  that  specifies  "whet-to-do-next" . This  parameter  in  colled  a 
, ^ cent i nuat i on . The  meaning  of  a program  fragment  is  in  general  also  a 

cost i nuot ion . Typically,  the  meaning  of  an  assignment  statement  with 

continue*  ion  c is  obtained  by  prefixing  c with  a store  to  store  transformation. 
In  fact.  Green  has  a sophisticated  exception  mechanism,  implying  the  us«  of  a 
> whole  exception  environment  associating  a continuation  to  each  exception 

handler . 

O Continuations  .ore  not  very  easy  to  understand  at  first.  The  Static  Semantics 

does  not  use  any  continuations,  so  that  it  is  possible  to  become  thoroughly 
familiar  with  the  Formal  Definition's  approach  before  having  to  tackle  this 
| O concept. 
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Sty! e of  the  Definition 

Given  that  the  first  objective  of  the  Formal  Definition  is  to  serve  as  a 
reference  document  for  implementors,  a great  deal  of  attention  must  be  given  to 
the  choice  of  the  mote-language , i.e.  the  language  in  which  Green  is  to  be 
formally  described.  The  typographical  conventions  of  the  Oxford  School  are  not 
suitable  for  such  an  audience,  due  to  an  intensive  use  of  Greek  letters  and 
diacritical  signs.  The  notation  proposed  by  Peter  Mosses,  (which  is  used  as 
input  for  his  system  SIS)  is  a much  better  candidate.  Mosses'  notation  is 
elegant,  machine  readable,  convenient  to  use  for  anybody  familiar  with 
applicative  programming  and  efficient  in  its  treatment  of  abstract  syntax.  In 
this  report,  we  have  tried  to  go  even  further  towards  usual  programming 
convention  in  using  an  (applicative)  subset  of  Green  itself  *s  a meta-language. 

A minor  notationel  extension  was  needed  in  order  to  allow  procedures  as 
arguments  and  results.  Italics  are  used  to  avoid  confusion  between  language 
and  metalanguage.  Identifiers  in  distinct  fonts  are  considered  to  be  distinct. 
It  is  hoped  that  the  increased  understandabi 1 i ty  of  the  Formal  Definition  will 
compensate  for  the  loss  of  elegance. 

In  keeping  with  the  goal  of  minimizing  the  number  of  new  notations,  we  have 
attempted  to  stay  close  to  the  terminology  of  the  Reference  Manual,  refraining 
from  introducing  new  names  unless  they  were  absolutely  necessary.  Furthermore, 
rather  than  presenting  the  Formal  Definition  as  a completely  separate  document, 
we  have  followed  the  structure  of  the  Reference  Manual.  The  equations  of  the 
Formal  Definition  intend  to  make  more  explicit  the  English  text  in  the  Reference 
Manual.  Experience  with  the  Formal  Definition  will  show  whether  this  is  the 
right  approach. 

As  a final  remark,  the  reader  will  notice  that  wo  make  use  of  the  abstraction 
facility  of  Green.  It  may  seem  unfortunate  that  we  could  not  avoid  using  one  of 
the  seemingly  more  advanced  features  of  th»  language.  Rut  in  fact,  all  we 
really  need  is  a way  to  specify  a collection  of  related  functions  together  with 
their  types.  This  concept  is  very  familiar  in  mathematics  as  an  algebra. 
Similarly,  the  use  of  *he  g ner'c  facility  corresponds  directly  to  the  notion 
of  a polymorphic  function  (or  functional)  in  mathematics.  In  fact,  all  (value 
returning)  procedures  defined  in  the  document  are  functions  in  the  mathematical 
sense.  The  sublanguage  of  Green  that  is  used  is  purely  'ppliestive  and  th^  only 
"side  effects"  are  the  construction  of  new  objects. 
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1.2 


Abstract  Representation  of  Programs 


In  this  section,  we  present  a standard  way  of  representing  programs.  It  is  to 
be  used  not  only  to  define  the  semantics  of  the  Green  language  but  also  as  a 
standard  interface  between  all  processors  manipulating  Green  programs.  Programs 
are  represented  as  trees,  called  Abstract  Syntax  Trees.  These  tre^s  are  defined 
with  the  help  of  the  Green's  encapsulation  Facility,  so  as  not  to  preclude 
subsequent  efficient  implementation. 


O 1.2.1  Motivations 


O 


O Since  the  meaning  of  programs  will  be  defined  recursively  on  their  structure,  it  O 

is  necessary  to  specify  with  great  precision  what  this  structure  is  before 
developing  the  Formal  Definition  per  so . On  the  other  hand,  quite  apart  from 
O the  Formal  Definition,  there  is  considerable  interest  in  standard! zing  the  O 

representation  of  programs.  This  standard  representation  will  play  a crucial 
part  in  the  harmonious  development  of  the  programming  support,  a collection  of 
O issues  addressed  in  Pebblcman.  Typical  tools  that  are  to  benefit  from  such  a O 

definition  arc:  syntax-oriented  editors,  interpreters  and  compilers, 

documentation  and  normalisation  rids,  program  analysers,  optimizers, 

O verification  tools.  O 
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We  now  list  some  requirements  that  an  abstract  representation  must  satisfy  to  be 

effective  as  a standard: 

(a)  It  must  be  possible  to  implement  it  efficiently  on  a variety  of  machines. 

(b)  It  mu3t  reflect  the  structure  of  programs.  For  example,  it  must  be  easy  to 
recognize  and  isolate  program  fragments  such  as  statements,  procedures, 
declarations,  expressions,  identifiers,  etc... 

(c)  It  must  be  easy  to  manipulate  and  modify. 

(d)  It  must  include  all  meaningful  information  contained  in  the  original 
program  text.  In  particular  it  must  be  possible  to  restore  the  program 
text  from  the  representation,  up  to  minor  standard i zat ions . 

(e)  It  should  not  be  cluttered  with  irrelevant  information. 

(f)  It  must  have  a simple  and  usable  mathematical  definition  sinc«  it  will  be  a 
foundation  for  the  Formal  Definition. 
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(g)  Finally,  *3  a matter  of  course,  it  must  allow  the  representation 
legal  Green  program. 


O 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 


Common  intermediate  languages  designed  for  optimization  fail  requirements  (b) 
through  (d) . Using  abstract  syntax , a method  put  forward  in  the  early  sixties 
[McCarthy,  Landin]  is  very  natural,  simple  end  meets  roou i r^ments  (?)  through 
(9)  . 


1.2.3  Abstract  Syntax  Trees 


The  essential  idea  underlying  abstract  syntax  is  the  treatment 
program  fragments  as  trees . For  examole,  the  assignment 

A :*  B 

will  be  (pictor iol ly)  represented  by  the  tree  t. 

assign 


programs  and 


id 


id 


Each  node  in  the  tree  is  labeled  by  a construct . Tn  cur  notation,  the  construct 
labeling  the  top  node  of  the  tree  t is  denoted  by  KTND(t)  . Here  KrwO(t)  ■ 
assign . The  subtree  representing  the  left-hand-side  of  the  assignment  is 
denoted  by  SON(l,t)  and  the  subtree  denoting  the  right-hand-side  by  S0M(2,t). 
The  whole  Green  language  is  defined  using  126  constructs.  Most  constructs  label 
trees  with  a fixed  number  of  sons.  These  constructs  are  said  to  be  of  f i xed 
ar  i ty . To  represent  lists,  it  is  necessary  to  us^  nodes  that  may  have  an 
arbitrary  number  of  sons.  For  example  the  fragment 


B 

D :« 


A; 

E; 


is  represented  as 


e 

o 

c 

o 

% 

o 

c 

o 

© 

o 

o 

o 


355 Ign 


assign 


id"8"  id"A" 


The  construct  esni 
labeled  stms  cou 


ld’D" 


Id  ”E” 


if 


n is  binary  while  stm  s is 


list  construct.  The  node 


have  an  arbitrary  number  of  sons. 
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Notat  ions ; All  Green  constructs  or'*  written  in  italics.  List  constructs  have 
names  ending  in  s , like  st~n  s , cxn  s , or  d c c .1  c . 

Not  ell  trees  labeled  with  constructs  ere  abstract  syntex  trees.  A grammar 
imposes  a restriction  on  the  strings  of  terminal  symbols  th.-t  ere  sentences  of 
the  language  it  defines.  The  Green  abstract  syntax  is  similarly  defined  by  a 
tree  grammar . It  specifies  precisely  wh i eh  trees  are  Green  trees.  Let  us 
da L ine  a sor t to  be  a set  of  constructs.  The  abstract  syntax  of  Green  is 
specified  with  the  help  of  57  sorts.  If  the  root  of  a tree  t is  a construct 
belonging  to  sort  s,  we  say  that  t is  of  sort  s.  The  entire  abstract  syntax  of 
Green  is  completely  specified  by  giving,  for  each  construct,  its  ority  as  well 
as  the  sort  of  each  son. 

Note  that  list  constructs  are  homogeneous:  all  constituents  of  a list  must  be 
of  the  same  sort. 

Not at  ions. 

(a)  Sorts  are  written  in  italics  and  is  capitalized  (o.g.  CQNQ) . When  a sort 
is  c singleton  sort  (i.o.  it  contains  a single  construct),  it  has  the  same 
name  os  its  member,  but  capi tal 1 zed . Furthermore,  since  list  constructs 
arc  characterized  by  the  common  sort  of  their  constituents,  their  name 
always  reflects  that  sort.  As  an  example,  a nod^  labeled  stm  s has 

subtrees  of  sort  ST?,-  a node  labeled  dec!  s has  subtrees  of  sort  DFCL. 


(b)  A notation  similar  to  ENF  has  been  used  to  specify  the  sorts.  When  writing 
for  example: 

COND  : : * EXP  ) condition 

we  mean  that  CONO  is  the  union  of  sort  FXP  and  the  singleton  sot  {condition}. 
Since  sorts  and  constructs  are  distinguished  typographically , the  symbol  Pis 
used  without  ambiguity.  For  each  construct,  a sequence  of  sorts  is  given.  For 
example  the  specification 

l£  ->  CONDITIONAL  S STM  S 

means  that  the  first  son  of  an  ^f  construct  is  of  sort  CONDITIONAL  S and  the 
second  son  is  of  sort  stm  s. 

Formally, 

SORT  OF  SON ( i f , 1 ) « CONDITIONAL  S 
S0RT”0F“50N(TT,2)  - 5Tfl"5 

In  the  case  of  list  constructs,  the  fact  that  all  constituents  . belong  to  the 
same  set  is  emphasized  by  the  use  of  three  dots  as  in 

stm  s ->  STM  . . . 

The  complete  Abstract  Syntax  of  Green  is  given  in  Appendix  A. 
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1.2.4  Encapsulat ion  of  the  Abstract  Syntax 


To  be  certain  that  the  abstract  syntax  of  Green  can  he  use'1,  as  a standard  for 
the  representation  of  Green  programs,  we  could  define  it  as  a Green  data 
structure.  This  would  not  however  leave  enough  room  for  efficient 
implementation  and  would  involve  unnecessary  and  harmful  over  spec! f iert ion . 
Rather,  we  specify  here  the  visible  par  t of  Green  Instead,  vie.  specify  here  the 
visible  part  of  Green  packages  tnat  provide  the  abstract  svntax  of  Green  end_  the 
too lp  foT  the.  manieiJla.tAon  o.f.  .Green  trees.,  Notice  rh.-t  the  procedure  "-'AKF  is 
ovc c Ioroed.  ‘inis  overloading  will  be  resolved  on  the  basis  of  the  number  of 
arguments  handed  to  it  in  any  call.  The  procedure  MAKE  must  be  programme-'  using 
the  KIND  end  S0RT_0F_S0N  procedures  provided  in  the  oackcgo  CREEN_SYNTAX , to 
check  that  it  is  not  asT<cd  to  build  unlawful  Green  trees.  Similarly,  the 
constructor  procedure  EMPTY  checks  that  its  .argument  is  a construct  of  arbitrary 
ar ity. 


Most  processors  will  find  the  selector  function  SON  perfectly  adequate.  For  the 
Formal  Definition,  where  readability  is  of  prime  importance,  we  have  assumed  the 
existence  of  a third  package,  GRFEN^SELECTORS . This  package  allows  us  to  rofor 
to  subtrees  by  name  rather  than  by""posi t ion . A simple  convention  for  the  names 
of  the  selectors  has  been  followed  in  th^  Formal  Definition:  for  each  sort  a 
selector  function  is  defined  that  is  named  after  the  sort.  Assume  now,  for 
example,  that  "if"  is  a tree  with  a root  labeled  j^f.  Instead  of  writing: 

SON (1 , t f ) 


we  may  write 

CONDITION'S (if) 

In  cases  like  the  binary  construct  pa i r that  has  more  than  one  son  of  the  same 
sort,  numbering  is  used.  Thus  EX PI (pair)  and  EXP2(pair)  return  the  first  and 
second  ion  of  the  tree  pair,  respectively,  as  both  are  of  sort  EXP . 


1.3  Structure  and  Notations 


In  the  informal  description  of  the  semantics  of  Green  given  in  the  Reference 

Manual,  one  can  distinguish  three  kinds  of  concerns: 

( i ) Some  features  of  the  language  are  provided  to  shorten  the  text  of  programs 
or  to  increase  their  readability.  These  features  arc  best  explained  as 
combinations  of  other  possibilities  of  Green. 

(ii)  A group  of  specifications  are  intended  to  delineate  the  class  of  legal 
programs,  within  the  class  of  syntactically  correct  on^c.  Considerations 
such  as  the  need  to  declare  every  identifier  used,  coherence  in  the  use  of 
types  and  resolution  of  ambiguity  in  the  use  of  overloading,  are  in  this 
category. 

(iii) The  rest  of  the  informal  definition  concerns  the  behavior  of  programs 
during  execution. 
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The  Formal  Definition  is  structured  to  reflect  these  quite  distinct  concerns. 


1.3.1  Normalization 

O 

This  part  of  the  Formal  Definition  specifies  transformations  of  the  abstract 
syntax  tree  that  do  not  require  any  type  information.  These  transformations  are 
O performed  to  eliminate  the  use  of  come  notation*'!  conveniences  or  to  check 

simple  syntactic  constraints.  They  are  defined  by  functions  mapping  TREE'S  to 
TRFE ' s and  given  in  Appendix  R.  Whenever  those  functions  are  suTTTciently 


o 

simple  (i.e.  involve 
rewriting  rule. 

no  context) , 

the 

text 

includes  their  description  os  a 

o 

Example : 

o 

I if  CONDITIONAL 
[ if  CONDITIONAL 

S else  STM  S 
elsif  true 

end 

then 

if;  1 ■ 
STM  S 

-> 

end  if;  ] 

The  kind  of  constraints  dealt  with  by  normal i ?at ions  must  require  only  little 
contextual  information,  i.e.  no  information  about  types.  For  example,  the 
Manual  states: 

"Within  the  sequence  of  statements  of  a subprogram  or  module  body, 
different  labels  must  have  different  identifiers." 

This  check  is  supposed  to  be  performed  in  this  normalization  phase. 

o 


O 1.3.2  Static  Semantics 


This  part  of  the  Formal  Definition  is  concerned  with  what  is  usually  celled 
type_checking.  A type  checker  is  given  as  a mapping  from  abstract  syntax  trees 
to  an  extended  abstract  syntax  tree.  This  is  intended  to  mimic  the  concepts  of 
"compile  time"  checks  as  opposed  to  "run  time"  checks.  Type_checked  programs 
contain  all  type  information  needed  at  run  time.  In  this  way  dynamic  semantics 
will  not  need  to  carry  a static  environment. 

The  Static  Semantics  of  Greer,  has  to  deal  with  the  following: 

1.  It  must  check  that  the  declarations  are  valid,  i.o.  there  is  no  repeated 
declaration  of  the  some  designator  in  the  same  scope.  It  must  check  that 
all  designators  are  declared. 

2.  It  must  check  that  all  designators  are  used  in  a manner  that  is  consistent 
with  their  type. 

3.  It  must  carry  out  the  evaluation  of  static  expressions  where  needed. 

4.  All  information  on  types  of  designators  must  he  used  to  generate  an 
extended  abstract  syntax  tree.  This  includes: 
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4.1  Detecting  and  el iminet ing  all  overloading 
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4.2  Reordering  actual  parameters  in  subprogram  colls.  Once  it  has  been 
processed,  o subprogram  call  will  list  all  its  parameters  in  named 
parameter  essociat ions. 

4.3  Normalizing  aggregates  as  lists  of  named  component  associations. 

4.4  Resolving  ambiguities  between  indexed  component,  qualified 
expression  and  subprogram  call. 


5.  Exception  names  are  mode  unique  within  a program 

6.  The  dot  notation  is  systematically  used  to  access  identifiers  visible 
through  a use  list. 

The  Static  Semantics  presented  here  is  parameterized  by 

a "machine"  that  abstracts  away  the  structure  of  the  static  environment, 
whore  information  regarding  the  type  of  designators  is  recorded.  The 
external  behavior  of  this  "machine"  is  defined  by  a set  of  functions  that 

- build  or  select  type  denotations 

- declare  or  access  designators 


a "machine"  which  abstracts  auxiliary  functions  used 

- to  solve  overloading 

- check  for  side  effects  of  functions  and  value  returning  procedures 


1.3.3  Oynamic  Semantics 


The  Static  Semantics  is  described  os  a transformation  performed  on  abstract 
syntax  trees.  The  Dynamic  Semantics  corresponds  more  to  the  customary  notion  of 
interpretation.  The  meaning  of  each  construct  is  defined  recursively  on  type 
checked  abstract  syntax  trees.  Information  about  the  identifiers  in  the  program 
(e.g.  the  value  of  a constant,  the  constraints  associated  with  a subtype)  is 
recorded  in  the  dynamic  environment. 

The  functions  used  in  Dynamic  Semantics  are  partitioned  into  three  groups, 
following  to  the  terminology  of  the  Reference  Manual: 

(a)  .Those  defining  the  elaboration  of  declarations  (Prefix  FLAP) . 

(b)  Those  defining  the  evaluation  of  expressions  (Prefix  AVAL). 

(c)  Those  defining  the  execution  of  statements  (Prefix  EXEC). 
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The  dynamic  semantics  is  also  par ameter i 2cd  by 

- an  abstract  machine  that  provides  a model  of  storage  allocation 

- a set  of  definitions  which  characterize  the  restrictions  of  a concrete 
machine  (minimum  and  maximum  value  for  integers#  etc). 


1.3.4  Treatment  of  Errors 

Errors  discovered  during  Normal i zat ion  and  during  the  checking  of  the  Static 
Semantics  are  reported  by  inserting  a special  construct  in  the  Abstract  Syntax 
Tree  at  the  lowest  meaningful  level.  The  Dynamic  Semantics  is  only  defined  on 
trees  which  do  not  contain  such  errors,  in  this  way,  the  place  and  reason  for 
an  error  are  defined.  Error  messages  can  be  standardized  accordingly. 

Errors  occurring  during  the  execution  of  a program  raise  the  appropriate 
exceptions,  as  prescribed  by  the  semantics  of  Green. 


Formal  Definition 


1 


12 


Prrl tminnry  Draft 


» 


Formal  Definition 


? - 1 


2.2  Lexical  Units  and  Spacing  Conventions 
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The  lexical  units  of  a program  are  identifiers  (including  reserved  words),  numbers,  strings,  end  delimiters.  A 
delimiter  is  either  one  of  the  following  special  characters  in  the  basic  character  set 

s' 

or  one  of  the  following  compound  symbols 
->  ..  **  :*  /-  >»  <»  <<  >> 

Spaces  may  be  inserted  freely  with  no  effect  on  meaning  between  lexical  units.  At  least  one  space  must 
separate  adjacent  identifiers  or  numbers.  Besides  terminating  a comment,  the  end  of  each  line  is  equivalent 
to  a space.  Thus  each  lexical  unit  must  fit  on  one  line. 


2.3  Identifiers 

Identifiers  are  used  as  names.  Isolated  underscore  characters  may  be  included  and  all  characters  are 
significant,  including  underscores. 

Syntax: 

identifier 

letter  {(underscore)  letter_or_ digit) 
lotter_or_ digit  letter  I digit 

letter  :t*  uppcr_ case_ let  ter  I lower_case_ letter 
Abstract  Syntax : 

id  ->  — (lexical  unit  ) 


O 


! O 


ID 

Note  that  identifiers  differing  only  in  the  use  of  corresponding  upper  end  lower  ease  letters  are  considered 
as  the  same. 


2.4  Numbers 


There  are  two  classes  of  numbers:  integers  for  exact  computation,  and  real  numbers  for  approximate 
computation.  Their  explicit  representation  is  given  here. 

Syntax; 

number  integer_number  I approximate_number 
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integcr_number  integer  I based_ integer 

integer  digit  ((underscore]  digit) 
bascd_integer 

base  * extended_dig it  ((underscore)  extended_digit) 
base  integer 

extended^ digit  digit  I letter 

approx imate_numher 

integeT. integer  ( E exponent] 

I integer  E exponent 

exponent  (+)  integer  I - integer 

Abstract  Syntax : 

int  number  ->  — ( lexical  unit  ) 
real  number  ->  — ( lexical  unit  ) 

Isolated  underscore  characters  may  be  inserted  between  adjacent  digits  or  extended  digits  of  a number,  but  are 
not  significant.  Spaces  may  not  appear  within  numbers. 

Based  integers  can  be  represented  with  any  base  from  2 to  16.  For  bases  above  ten,  digits  may  include  the 
letters  A through  F with  the  conventional  meaning  10  through  15. 

2.5  Character  Strings 

A character  string  is  a sequence  of  zero  or  more  characters  prefixed  and  terminated  by  the  string  bracket 

character  (the  double  quote  " or  its  replacement  the  % character). 

Syntax: 

character_str ing  " (character)  " 

Abstract  Syntax : 

string  ->  — f lexica]  unit  ) 

In  order  that  arbitrary  strings  of  characters  may  be  represented,  any  included  string  bracket  character  must 
be  written  twice.  The  length  of  a string  is  the  length  of  the  sequence  represented.  Strings  of  length  one 
are  also  used  for  literals  of  character  types  (see  3.5.1).  Strings  longer  than  one  line  must  be  represented 
using  catenation. 

A character  string  may  contain  characters  not  in  tha  basic  character  set.  A string  containing  such  characters 

can  bo  converted  to  a string  written  with  th*'  basic  character  set  by  using  identifiers  denoting  these 

characters  in  catenated  strings.  Such  identifiers  are  defined  in  the  predefined  environment.  Thus  the  string 
"AB$CD"  could  be  written  as  "AB"  6 DOLLAR  & "CD".  Similarly,  the  string  "APcd"  with  lower  case  letters  could 
be  written  as  "AP"  » LC  C S LC  b. 
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2.6  Comments 


A comment  starts  with  a double  hyphen  and  is  terminated  by  the  end  of  the  line.  It  may  only  appear  following 
a lexical  unit  or  at  the  beginning  or  end  of  .a  program  unit.  Comments  have  no  effect  on  the  meaning  of  a 
program;  their  sole  purpose  is  the  enlightenment  of  the  human  reader. 


2.7  Pragmas 


Pragmas  are  used  to  convey  information  to  the  compiler.  A pragma  begins  with  the  reserved  word  pragma 
followed  by  the  name  of  the  pragma.  A pragma  can  have  arguments,  which  can  be  identifiers,  strings,  or 
numbers. 

pragma 

pragma  identifier  [(argument  {,  argument})]; 
argument  identifier  I character__str ing  I number 

Pragmas  may  appear  before  a program  unit,  and  wherever  a declaration  or  a statement  may  appear.  The  extent  of 
the  effect  of  a pragma  depends  on  the  pragma. 

A pragma  may  be  language  defined  or  implementation  defined.  All  language  defined  pragmas  are  described  in 
Appendix  B. 

2.8  Reserved  words 

The  identifiers  listed  below  are  celled  reserved  words  end  are  reserved  for  special  significance  in  the 
language.  As  such,  these  identifiers  may  not  be  declared  by  the  programmer.  For  readability  of  this  manual. 
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reserved 

words  appear 

in  lower  cose 

bold  face . 

! 

abort 

declare 

generic 

of 

select 

° i 

accept 

delay 

goto 

or 

separate 

access 

delta 

others 

subtype 

C | 

all 

digits 

out 

and 

do 

if 

• 

array 

in 

package 

task 

G ! 

assert 

initiate 

packing 

then 

at 

else 

is 

pragma 

private 

type 

elsif 

end 

loop 

procedure 

use 

V. 

begin 

entry 

raise 

body 

exception 

mod 

range 

exit 

record 

when 

renames 

while 

new 

restricted 

* 

case 

for 

not 

return 

constant 

function 

null 

reverse 

xor 
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3.  Declarations  and  Types 

This  chapter  describes  the  types  in  the  language  and  the  rules  for  declaring  constants  and  variables. 

3.1  Declarations 

A declaration  associates  an  identifier  with  a declared  entity.  Each  identifier  must  be  declared  before  it 

used,  with  the  exception  of  labels.  There  are  several  kinds  of  declarations. 

Syntax : 

declaration 

Object_declaration  I type^dccl arat ion 

| subtype_declar?t ion  I private  typc_doclnret ion 

I suborog7am_declnrat ion  I module  <Jccla7ation 

| entry^declara  t ion  I exccpt.7on_decl ar at  ion 

I renam7ng_dcclaret ion 


i s 


Abstract  Syntax : 

doc!  ->  NATURE  DESIGNATOR  S DESCRIPTION 

designator  s ->  DESIGN ATOR  ...  --  f DESIGNATOR , ...  1 

NATUPE  : : ■ constant  I variable  I type  I subtype  I private  I procedure  I f unct ion  I 

i I exception  I in  I out  ' -- 


Pormal  Definition 


Preliminary  Draft 


o l 

i 

o I 

I 

o ! 

o 

o 

o 

o 

G 


' n 

DESIGNATOR  3 ::= 

designator  s 

DESIGNATOR 

DESCRIPTION 

id  ! string 

Tnstant irtion  1 obiect  1 renamino  1 typo  1 unit  1 void 

^ ! 

o 

— Depend ino  on 

its  nature,  a dec]  may  appear  as: 

1 

c i 

— [DESIGNATOR  S 

: constant  DESCRIPTION] 

j 

--  [DrsT  gN-'TOF 

: DESCRIPTION! 

o 

— [type 

r<-cTC  -\-.Cp  5 ls  prejcPTPTICN] 

— [subtype 

rGcT^'-.MGr  s is  cr«CRiDT:r':; 

— [restricted  type  r.nsr'f'-'T'P  ' is  rSSCRIPJ  ICl 

w 

— [procedure 

PESIGN-vj-rP  s rFSCPIPTI^Nl 

— [function 

DESIGNATOR  S DESCRIPTION! 

— [package 

DES T S TOP  c DESCRIPTION] 

w 

— Itask 

DES I Gl « A 7 OP  S DESCR T PT ION ] 

V-e  | 

— (entry 

DESIGN  ATOP.  S DESCRIPTION] 

j 

o 

— [DESIGNATOR  S 

exception] 

c 1 
» 

— [DESIGNATOR  S 

in  DESCRIPTION] 

— [DESIGNATOR  S 

out  DESCRIPTION] 

i 

• 

— [DESIGNATOR  S 

in  out  DESCRIPTION! 

mk  '-♦*'* 
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The  process  by  which  a declaration  achieves  its  effect  is  celled  the  olaboraH on  of  the  declaration.  Any 
expression  appearing  in  a declaration  is  evaluated  when  the  declaration  is  r i abo rated  unless  otherwise  stated. 

Object,  type,  and  subtype  declarations  are  described  here.  The  remaining  declarations  are  described  in  later 
chapters. 

Static  Semantics: 


procedure  CHECK_DECL_S  (decl_s:  TREE?  env:  S ENV;  local:  s ENV)  return  TREE  ENV  is 
begin 

if  IS  EMPTY (decl  s)  then 

return  TREE_ENV(EM»>TY  (decl_s)  , local); 
else 

declare 

tree  env  : constant  TREE  ENV  CHECK_DECL (MEAD (decl_s) , env,  local); 

locaT2  : constant  S F.,|V  :*  ENV(trcc  env); 

env2  : constant  S F.'IV  :■  NESTED  ENV(env,  local2); 

trec_env2:  constant  TREE  ENV  :-  CHECK_DECL_S (TAIL (decl__s) , cnv2,  local2) ; 
begin 

return  TREE_ENV(PRE (TREE (troe_env) , TREE (tree  env2)),  ENV ( trec__env2) ) ; 

end; 
end  if; 

end  CHF.CK_DECL_S; 


procedure  CHECK_DECL(decl : TREE?  env:  S ENV;  local:  S ENV)  return 
begin 

case  KIND (DESCRIPTION (decl ) ) of 


when  instantiation 
when  object 
when  rf- naming 


when  ty»:e 
when  unit 
when  voio 
end  case; 
end  CHECK  DECL; 


DECL  INSTANTIATION (decl , 


DECL  OPJECT 
DECL~RENAMING 
DECL~TYPE 
DECL~UNTT 
DECL  EXCEPTION 


(decl , 
(decl , 
(decl , 
(decl , 
(decl i 


env, 
env , 
env , 
env , 
env , 
env, 


local ) 
local) 
local) 
local ) 

3 ocal ) ; 
1 ocal ) ; 


TREE  ENV  is 


procedure  CHECK_DESIGNATOR_S (designators:  TREE;  env:  S ENV;  den:  S PEN)  return  TREE  ENV  Is 
begin 

if  I S^EMPTY (designator  s)  then 

return  TREE_J5NV (designators,  env); 

else 

declare 

tree  env  : constant  TREE  ENV  CHECK_DESlGNATOR  (HEAD (designator's) , env,  den); 

tree“env2:  constant  TREE  ENV  CHECKJJESIGNATOFJ?  (TAIL (des ignator_s) , ENV(trec  env),  den); 

begin  " 

return  TREE_ENV(PRE(TREE(tree_env) , TREE  ( tree__env2) ) , ENV(treo  env2)); 
end; 

end  if; 

end  CHECK_DESIGNATOR_S; 
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procedure  CHECK__DESIGNATOR  (designator : TREE?  env:  5 CUV;  den:  s pen1)  return  TREE  ENV  is 

begin 

if  I S_OVFR LOADABLE (DEN  OF (designator , env)  , den)  then 

reYurn  TREE__ENV (designator , OVERLOAD(dosignctor , env,  don)); 
elsif  TSJTORV.'ABD  (OEN_OF  (designator,  env)  ) then 

return  TREE_ENV  (design.?  tor  , UPDATE  (designator  , env,  den)); 
elsif  not  ( IS__DECLARFD  (designator,  env))  then 

return  TPEE_ENV (designator , UPDATE (designator , env,  den)); 
else 

return  TREE__ENV  (ALRE.ADY__DECLARF,D,  env)  ; 
end  if; 

end  CHECK_DESIGNATOR; 


3.2  Object  Declarations 


An  object  is  a variable  or  a constant.  An  object  declaration  introduces  one  or  more  n.amed  objects  of  a given 
type.  These  objects  can  only  have  values  of  this  type. 

Syntax : 

object_declarat ion 

identifier's  : [constantj  type  [;*  expression); 
identifiers  identifier  {,  identifier) 

Abstract  Syntax : 

object  ->  TYPE  EXP  VOID  — [TYPE  :■  EXP)  or  [TYPF ) 

Description : 

An  object  declaration  may  include  an  expression  which  specifies  the  initial  value  of  the  declared  objects. 
This  expression  is  evaluated  and  its  value  is  assigned  to  each  of  the  declared  objects,  as  part  of  the 
elaboration  of  the  object  declaration. 

An  object  is  a constant  if  its  declaration  includes  the  reserved  word  constant.  The  value  of  a constant  cannot 
be  modified.  If  a constant  object  has  components,  they  cannot  be  modified. 


It  is  possible  to  defer  the  initialization  of  a constant  record  component  (see  3.7.1)  and  of  a constant  of  a 
private  type  declared  in  the  visible  part  of  a module  (see  7.4). 

Static  Semantics: 

procedure  DECL  OBJECT(decl : TREE;  env:  S ENV;  local:  S ENV)  return  TREE  ENV  is 
nature  constant  TREE  :«  NATURE  (docl); 

.designator's:  constant  TREE  :*  DESIGNATOR  S(decl); 
object  : constant  TREE  DESCRIPTION  (decl); 

x begin 

case  KIND(nature)  of 

when  constant  I — [DESIGNATOR  S:  constant  DESCRIPTION) 
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var i ?b1 e | 
J n I 
out  I 
ip  out  I 
*> 


(DESIGNATOR  S : 
[DESIGNATOR  S: 
( DESIGNATOR”^ : 
(DESIGNATOR'S: 


DESCRIPTION ) 
in  DESCRIPTION ) 
out  DESCRIPTION) 
in  out  DESCRIPTION] 


declare 

tree_des_den  : constant  TPFE  DES  PEN 

object2  : constant  TREE 

don  s constant  s DEN 

trec_cnv  : constant  TREE  ENV 

d'?signator_s2:  constant  tree 
begin 

return  TREE  E?IV (MAKE  (docl , nature,  do 
end; 

when  others  *> 

return  TREE_ENV(SYNTAX_ERROR,  local); 
end  case; 
end  DECL  OBJECT ; 


• CMRCK__03JECT  (object , onv)  ; 

• TPFE (tree  des__den)  ; 

« DEM  (nature,  D^SDEN (t recedes  den); 

1 CHECk  DESIGNATOR  S (designator  s,  local, 
■ TREE  ( t reo__env)  ; 

gnetor_s?,  object2)  , Fnv ( trec_env) ) ; 


don)  ; 


procedure  CHECK  OBJECT (object : TREE;  env:  S ENV)  return  TREE  DES  DEN)  is 

t ree__type_cen’:  constant  TREE  TYPE  :-  CHECK_TYPE__CONSTRMMT  (TYPE  (object)  , env); 
cxp_void  : constant  EXP  VOID  :*  „CHECK_EXP_VOID (EXP_VOTD (object) , env); 

des“den  : constant  S deg  PEN  :»  DES_ DEN (TYPE— DEN ( t7ec_typc_ den) , cxp__void) ; 

begin 

return  TREE  DES  DEN (MAKE (object , TREE(tree  type),  exo  void),  des  den); 
end  CHECK  OBJECT; 


3.3  Type  and  Subtype  Declarations 


A type  characterizes  a sot  of  values  and  a set  of  operations  applicable  to  those  values.  The  values  are 
denoted  by  literals  or  aggregates  of  the  type,  or  can  be  obtained  as  the  results  of  operations.  The  operations 
and  the  properties  of  the  values  are  said  to  be  at t r i butes  of  the  typo.  Any  subprogram  with  a parameter  or 
result  of  the  type  is  an  attribute  of  the  type. 

There  exist  several  classes  of  typos.  Scalar  typos  are  types  whose  values  have  no  components;  they  comprise 
types  defined  by  enumeration  of  their  values,  integer  types,  and  real  typos.  Ar ray  and  record  typ*»s 
composite;  their  values  consist  of  several  component  values.  An  errors  type  is  a typo  whose  values  provide 
access  to  other  objects.  The  attributes  resulting  from  the  definition  of  those  classes  of  typos  arc  predefined 
attributes  (see  4.1.3).  Finally,  there  are  pr ivatc  types  whore  the  set  of  possible  values  is  clearly  defined, 
but  not  known  to  the  users  of  such*  types.  Hence,  a private  type  is  only  known  by  the  set  of  operations 
applicable  to  its  values  (see  7.4). 

The  set  of  possible  values  of  a type  can  be  restricted  without  changing  the  set  of  applicable  operations.  Such 
a restriction  is  called  a constraint . A value  is  said  to  belong  to  a subtype  of  a given  type  if  it  obeys  such 
a constraint.  Naturally,  suVtypw may  not  be  found  for  user  defined  private  types  since  nothing  is  known  a 
prior i about  the  set  of  possible  values. 


Syntax : 
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type  :t»  t.ype_  def  Ini  tlon  | type_mark  [constraint) 
typo  definition 

enumere  t lon__tyne_de f ini  t ion  I intrger_typo_dof  ini  t ion 
I real_ type^d'ef  iniTion  ) arrey_typo__def  i n i t ion 

I record  typo_ dof inition  I access_type_def inition 

I dorivc<T_typc_def inition 

typejrark  type  name  I subtype  nemo 

constraint 

range__constraint  I accuracy__constrai  nt 
I index__constraint  I discr iminant_constrnint 

type_declarrt ion 

type  identifier  [is  type_definition) ; 
subtypc_declarat ion 

subtype  identifier  is  typo__merk  [constraint); 

Abstract  Syntax : 

docl  ->  NATURE  • DESIGNATOR  S DFfSCRTPTION 

constrained  ->  NAME  CONSTRAINT 

TYPE  : : * access  I ar  ray  I comp  s I constra  i ned  I 

derived  I designator  s I f i xed  I float  \ 

integer  I nr ive to  f restricted  private  f Void 


CONSTRAINT  : : » fixed  | float  I comp  assoc  s ! cai r 1 

tvoed  pair  I range  s I void 

Poser iot ion; 

Every  type  definition  introduces  a distinct  type.  A type  declaration  associates  a name  with  a type.  A subtype 
declaration  introduces  a name  as  an  abbreviation  for  a type  name  with  some  possible  constraint.  Each 
constraint  is  evaluated  when  the  declaration  in  which  it  appears  is  elaborated. 

An  incomplete  type  declaration  of  the  form 

type  T; 

is  used  for  the  declaration  of  mutually  dependent  access  types  (see  3.0);  the  complete  type  declaration  must 
follow  in  the  same  declarative  part. 

3.4  Derived  Type  Definitions 

A derived  type  definition  introduces  a new  type  deriving  its  characteristics  from  those  of  an  existing  type. 


der ived_typc_def inition  new  type_mark  [constraint! 
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:tr 


With  a type  declaration  of  the  form: 
type  NEWJTYPE  1 3 new  OLDJTYPE; 

the  new  type  derives  ell  its  characteristics  from  those  of  the  old  type: 

- The  new  type  belongs  to  the  same  class  of  types  as  the  old  type  (for  example,  the  new  type  is  a record 
type  if  the  old  type  is)  and  the  same  attributes  ar*  predefined. 

- The  set  of  values  of  the  new  type  is  a copy  of  the  set  of  values  of  the  old  type.  The  constraints 
associated  with  the  old  type  apply  to  objects  of  the  new  type. 

- The  notation  for  literals  or  .aggregates  of  the  new  type  is  th^  same  as  for  the  old.  Such  literals  and 
aggregates  arc  said  to  be  over  loaded . The  notation  used  to  denote  components  of  objects  of  the  new  type 
is  the  same  ns  for  the  old. 

For  each  visible  subprogram  attribute  of  the  old  type,  a subprogram  attribute  of  the  new  type  is  derived 
in  which  occurrences  of  the  name  of  the  old  type  ere  in  effect  replaced  by  name  of  the  new  type. 
Such  subprocirams  arc  said  to  be  overloaded.  Assignment  is  available  for  the  new  type  if  it  is  for  the 
old.  ' 

- Any  explicit  representation  specification  (see  13)  given  for  the  old  type  also  applies  to  the  new  type. 

The  effect  of  such  a type  declaration  is  thus  to  create  a new  type  distinct  from  the  old  type,  but  equivalent 
in  effect  to  whet  would  bo  obtained  by  duplicating  the  old  typo  definition  and  all  its  applicable  operations. 
Explicit  conversions  are  allowed  between  the  old  type  and  the  now  type  (see  4.6.2). 

A type  declaration  of  the  form: 

type  NEWJTYPE  is  new  OLDJTYPE  constraint; 

is  equivalent  to  the  succession  of  dcclar at  ions : 

type  new  tyoc  is  new  OLDJTYPE ; 
subtype  NEWJTYPE  is  now  tyoo  constraint; 

where  new  type  is  an  identifier  distinct  from  those  of  the  program.  Hence,  the  values'  and  operations  of  the 
old  typo  are  inherited  by  the  new  type,  but  objects  of  the  new  typo  must  satisfy  the  added  constraint. 


3.5  Scaler  Types 


Scalar  types  comprise  discrete  types  and  real  types.  Discrete  types  are  the  enumeration  types  and  integer 
types;  they  may  be  used  for  indexing  and  iteration  over  loops.  Numeric  types  are  the  integer  and  real  types. 
All  scalar  types  are  ordered.  A range  constraint  specifies  a subset  of  values  of  the  type  or  subtype. 

Syntax : 

range^constraint  range  range 

range  simple_express ion  ..  simple^ expression 
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FXP 

PAIR 


— (EXP  ..  EXP] 

— [NAME  range  PAIR] 


Abstract  Syntax : 

pair  ->  EXP 

typed  pair  ->  NAME 

RANGE  : : » pa i r | typed  pair 
PAIR  : pair 

Poser i pt i on ; 

The  range  L ..  P describes  the  values  from  L to  R inclusive.  An  empty  range  is  a range  for  which  L is  greater 

th3n  P.  The  type  of  the  simple  expressions  in  a range  constraint  is  the  typo  for  which  tho  range  constraint  is 

specified . 

Predefined  At  tr  ibuter. 

For  any  scalar  type  or  subtype  T,  the  following  attributes  are  predefined  (see  also  4.1.3  and  Appendix  A): 

T' FIRST  the  minimum  value  of  the  type  or  subtype  T 

T'LAST  the  maximum  value  of  the  type  or  subtype  T 

For  every  discrete  typo  or  subtype  T,  tho  subprogram  attributes  T'SUCC,  T’PFEO,  end  T'ORD  arc  predefined  as 
follows : 

T'SOCC(X)  the  value  succeeding  the  value  X in  T 
T’PRED(X)  the  value  preceding  the  value  X in  T 

T'ORD(X)  the  ordinal  position  of  the  value  X in  T.  For  example  T’ORD (T* FIRST)  * 1 

The  exception  RANGE_ERROR  is  raised  by  the  function  call  T' SUCC (T* LAST)  and  similarly  by  T ' PRED (T' FIRST) . 

3.5.1  Enumeration  Types 

An  enumeration  type  definition  introduces  a set  of  values  by  listing  the  values. 

Syntax : 

enumerat ion_type_dcf init ion 

(enumera t ion_Ti teral  {,  enumerat ion^l i teral )) 

enumeration_litorel  identifier  I character_l iteral 

Abstract  Syntax : 

designator  s ->  DESIGNATOR  ...  I DESIGNATOR , ...1 

DESIGNATOR  : string  I id 
Description: 
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An  enumerated  value  is  represented  by  an  identifier  or  a character  literal.  Hence,  a character  set  can  be 
defined  by  rn  enumeration  type.  Order  relations  between  enumeration  vaues  follow  t-he  order  of  listing,  tho 
first  being  less  than  the  last. 

Within  a sequence  of  declarat ions,  an  enumeration  literal  can  appear  in  different  enumeration  types.  Such 
enumeration  literals  are  said  to  be  over  loaded . When  ambiguities  arise  in  the  use  of  such  literals  they  can  be  -* 

resolved  by  providing  an  explicit  aual if iention  (see  4.6). 

^ ! 

3.5.2  Character  Types 


A character  type  is  an  enumeration  type  that  contains  character  literals  and  possibly  identifiers.  The  i 

predefined  type  CHARACTER  denotes  the  full  ASCII  character  set  of  128  characters  (see  •’'cccrdix  C)  . \ 
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3.5.3  Boolean  Type 
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There  is  a predefined  enumeration  type  named  BOOLEAN.  It  contains  the  two  literals  FALSE  and  TRUE  ordered  with 
the  relation  FALSE  < TRUE.  The  evaluation  of  conditions  delivers  results  of  this  predefined  type. 


3.5.4  Integer  Types 


The  predefined  type  named  INTEGER  denotes  a subset  of  the  integers.  Other  integer  types  can  be  introduced  by 
integer  type  definitions  or  can  be  derived  from  the  type  INTEGER. 


i 

c ! 
o ! 
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Syntax: 

intcger_type_def ini t ion  range_constraint 

Abstract  Syntax : 

integer  ->  PANGF 
Dnscr iption: 

The  range  of  integer  numbers  is  implicitly  limited  by  the  representation  adopted  by  an  individual 
implementation.  An  implementation  may  have  predefined  types  such  as  SHORT_INTEGER  and  LONG_INTEGER,  which  have 
respectively  shorter  and  longer  ranges  than  INTEGER. 

A type  declaration  of  the  form 

type  T is  range  L ..  P; 

where  L and  P denote  integer  values,  introduces  an  integer  type  equivalent  to 
type  T is  new  integer  type  range  L ..  R; 
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where  the  intcoer  tvoe  is  inolicitly  chosen  so  as  to  contain  the  values  L through  R and  is  one  of  the 
predef ined  types  such  as  SHORT_INTEGER,  INTEGER , or  LONG_INTEGER. 

3.5.5  Real  Types 

Real  types  provide  approximations  to  the  real  numbers,  with  relative  bounds  on  errors  for  floating  point 
types,  end  with  absolute  bounds  on  errors  for  fixed  point  type3. 

Syntax : 

roal_ type_dof init ion  accuracy^ constraint 


For  fixed  point  types,  the  error  bound  is  specified  as  an  absolute  value,  called  the  delta  of  the  fixed  point 
type.  The  implemented  error  bound  must  be  at  least  as  fin?  as  the  specified  delta,  in  a fixed  point  type 
definition,  the  range  constraint  cannot  be  omitted,  since  this  determines  the  representation  to  be  used  for 
values  of  the  type;  the  expressions  specifying  the  range  end  the  delta  must  be  static  expressions. 

In  a subtype  or  object  declaration,  an  accuracy  constraint  can  be  applied  to  a previously  declared  real  type. 
For  a fixed  point  type,  the  delta  of  the  constraint  cannot  be  smaller  than  the  delta  of  the  type.  For  a 
floating  point  type,  the  number  of  digits  specified  in  th«  censor.- in*  cannot  hr  larger  th->n  that  of  the  type. 
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accuracy  constraint 

digits  simple__exprcss  ion  [ range_constraint] 

1 delta  simple_expression  ( renge_ const ra intj 

o o 

Abstract  Syntax: 

i 

o 

float  ->  EXP  RANGE  VOID  — [digits  EXP  RANGE  V0ID1 

f i XCO  ->  EXP  RANGE  VOTD  — [delta  FXP  RANGE  VOIOl 

° ' 

o 

RANGE  VOID  void  1 RANGE 

O ! 

O 

D^scr ipt ion : 

! 

° i 

o 

For  floating  point  types  the  error  bound  is  specified  as  a relative  precision  by  giving  the 
decimal  digits  for  the  mantissa. 

minimum  number  of 

1 

o : 

• 

o 

A given  implementation  can  have  predefined  floating  point  types,  such  as  SHORT_FLOAT,  FLOAT, 
which  correspond  to  the  hardware  supplied  floating  point  types.  Real  type  definitions  of  the 

and  LONG_FLOAT, 
forms 

1 

o j 

o 

digits  p 

digits  P range  L ,,  R 

i 

! 

O i 

O 

where  P is  a static  integer  expression  (see  4.8)  specifying  a number  of  decimal  digits,  and 
floating  point  values,  are  equivalent  to  the  type  definitions 

where  L and  R are 

1 

1 

e ! 

G 

new  floating  point  tyoe  digits  P 

new  floating  ooint  tyre  diqits  P ranqe  L ..  R 

1 

. i 

J 

u 

where  floatinq  point  tyoc  is  implicitly  chosen  as  an  acorooriate  ©redefined  floatino 
implemented  precision  must  bo  at  least  that  of  the  precision  specified  in  the  corresponding 
range  is  provided,  it  must  be  covered  by  the  chosen  predefined  type. 

point  type.  The 
definition.  If  a 

In  all  cases,  the  delta  or  the  digits  must  be  given  by  static  expressions. 

Predefined  Attributes 

For  a floating  point  type  or  subtype  T,  the  following  attributes  are  predefined: 

T 'DIGITS  the  specified  number  of  digits  (it  is  of  type  INTEGER) 

T'SMALL  the  smallest  positive  value  expressible  with  the  representation  and  precision  of  type  T 
T* LARGE  the  largest  positive  value  expressible  with  the  representation  and  precision  of  tyre  T 
For  a fixed  point  type  or  subtype  T,  the  following  attribute  is  predefined: 

T' DELTA  the  value  of  the  specified  delta 

For  any  real  type  T the  following  attribute  is  predefined: 

T'DITS  the  minimum  number  of  bits  needed  for  the  representation  of  the  mantissa  of  T 


3.6  Array  Types 


An  array  object  is  a set  of  components  of  the  same  component  type.  A component  of  an  array  is  designated 
using  one  or  more  index  values  belonging  to  specified  discrete  types. 

Syntax: 

array_type  definition  * 

array  (Index  {,  index})  of  type_mark  (constraint] 
index  discrete^ range  I type_mark 

discrete_range  l type_ mark  range]  range 

index_constraint  (discrete_range  {,  discrete_range} ) 

Abstract  Syntax : 

array  ->  SOUNDS  S TYPE  — (array  BOUNDS  5 of  TYPE] 

bounds  s ->  BOUNDS  ...  — (BOUNDS  , ...J 

BOUNDS  : : * _^d  } indexed  ! pair  ) predefined  1 

selected  j typed  pair 
POUNDS  S : :■  bounds  1 

Description: 

An  array  object  is  characterized  by  the  number  of  indices,  the  type  of  each  index,  the  lower  and  upper  bound 
for  each  index,  and  the  type  and  possible  constraints  of  the  components.  In  an  array  type  definition,  each 
index  can  be  specified  either  by  a discrete  range  or  by  a type  mark.  Th^so  two  forms  of  index  specifications 
have  different  consequences: 
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( 1 ) Index  spec  i f 1 '•'d  by  £ discrete  range 

For  oil  objects  of  the  array  typo,  the  discrete  rang*  determines  both  the  permitted  type  for  the  index 
values  and  the  lower  and  upper  bound  for  the  index  values. 

(2)  Index  speci f ied  by  o type  mark 

For  oil  objects  of  the  array  type,  the  type  mark  only  determines  the  permitted  type  for  the  index  values. 
The  actual  values  of  the  lower  and  upper  bound  of  the  index  considered  can  be  different  for  different 
objects  of  the  array  type. 

The  bounds  must  be  given  for  each  array  separately  in  its  object  declaration  by  an  index  constraint,  or 
can  be  obtained  from  the  initial  value.  For  an  array  formal  parameter,  the  bounds  are  obtained  from  the 
actual  parameter. 

For  a multi-dimensional  array,  if  one  index  position  is  specified  by  a discrete  range,  all  index  positions 
mus$  be  specified  by  discrete  ranges.  Similarly,  '''n  index  constraint  must  provide  ranges  for  all  index 
positions.  For  accessing  components,  an  n-d imensional  array  is  equivalent  to  a one-dimensional  array  of 
(n-1 ) -dimensional  subarrays. 

If  the  bounds  of  a discrete  range  are  integer  numbers,  these  are  assumed  to  be  of  the  predefined  type  INTEGER 
if  their  type  is  not  otherwise  known  from  the  context. 
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Predefined  Attributes 


For  an  array  object  A (or  for  on  array  type  A with  specified  bounds),  the  following  attributes  are  predefined 
U is  on  integer  value) : 


A*  FIRST 
A • LAST 
A 'LENGTH 


the  lower  bound  of  the  first  index 
the  upper  bound  of  the  first  index 
the  number  of  components  of  the  first  index 
(zero  when  no  components) 


A' FIRST (i) 
A' LAST  (_i ) 

A' LENGTH  (i) 


the  lower  bound  of  the  i-th  index 
the  upper  bound  of  the  7-th  index 
the  number  of  components  of  the  index 


The  range  of  each  index  of  an  array  must  be  known  when  the  declaration  of  the  array  is  elaborated  (or  when 
allocated  in  the  case  of  access  types).  The  expressions  defining  the  range  of  an  index  nerd  not  be  static, 
but  can  depend  on  computed  results.  Such  arrays  are  called  dynamic  arrays . Tn  records,  dynamic  arrays  may  only 
appear  when  the  dynamic  bounds  are  discriminants  of  the  record  type. 
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3.6.2  Aggregates 


o 


An  aggregate  denotes  an  array  or  record  value  constructed  from  component  values. 
Syntax : 

aggregate 

(component_essociation  (,  component_associat ion) ) 


U 

U 


Fortml  Definition 


3-11 


Pr^l  tin i nary  Draft 


coroponent_associat ion  »:* 

(choice  {I  choice}  •>  } expression 

choice  simple_oxpression  I discrete^ range  I others 

Abstract  Syntax : 


cox.c  assoc  s ->  COMP  ASSOC  . . . 
n-:  ■re,4.  ->  CHOICE  S EXP 
choice  s ->  CHOICE  ... 


— [(comp  assoc,  ...)} 

-'-  [CHOICE  S ->  r.YP] 

— [CHOICE  I ...  ) 


COMP  ASSOC  named  I all  I r 1 1 oca  tor  | binary  I call  I 

co-ae  assoc  s I id  I int  number  I i ndex^d  I 

rooT.bc  r'sh ) p I null  I pr-^^cf  in^d  I ouM  i f fed  I 

real  number  I selected  I selected  string  j slice  I 

string  I unary 

CHOICE  S : :*  choice  s 

Choice  : :*  exp  i others  | r&nce 

The  expressions  define  the  values  to  be  associated  with  components.  They  can  be  given  by  position  (in  index 
order  for  array  components,  in  textual  order  for  record  components)  or  by  naming  the  chosen  components  (with 
index  values  for  array  components,  with  the  corresponding  identifiers  for  record  components).  An  aggregate 
defining  the  value  of  an  object  must  provide  values  for  all  components  of  the  object. 

For  named  components,  the  expressions  can  be  given  in  any  order,  but  if  both  notations  arc  used  in  one 
aggregate,  the  positional  component  associations  must  be  given  first. 

A choice  given  as  a discrete  range  stands  for  all  index  values  in  the  range.  The  choice  others  stands  for  all 
components  not  specified  by  previous  choices  and  can  only  appear  last.  Choices  with  discrete  values  are  also 
used  in  variant  pa’rts  of  records  and  in  case  statements.  Each  choice  may  only  appear  once  in  an  aggregate 
(variant  part  or  case  statement)  and,  except  for  the  choice  others,  its  value  must  be  determinable  statically. 

when  an  aggregate  used  as  an  initial  value  is  expected  to  provide  the  bounds  of  an  array  object,  the  choice 
others  cannot  be  used.  For  an  array  whose  index  is  only  specified  by  a type  mark  T,  the  lower  bound  is 
assumed  to  be  equal  to  T ' FIRST  if  the  initiali2at ion  is  given  by  a positional  aggregate. 

An  aggregate  for  an  n-dimensional  array  is  written  as  a one-dimensional  aggregate  of  components  that  are 
(n-1) -dimensional  array  values. 


3.6.3  Strings 

The  predefined  type  STRING  denotes  one-dimensional  arrays  of  the  predefined  type  CHARACTER,  indexed  by  values 
of  the  predefined  subtype  NATURAL: 

subtype  NATURAL  is  INTEGER  range  1 ..  INTEGER ' LAST; 
type  STRING  is  array  (NATURAL)  of  CHARACTER; 

Character  strings  (see  2.5)  are  a special  form  of  aggregate  applicable  to  the  type  STRING  and  other 
one-dimensional  arrays  of  characters. 


4 
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•**•*— *•! 

r> 

Catenation  is  a predefined  operator  over  one-dimensional  arrays,  and  is  represented  as  6.  For 

corresponds  to  the  following  function; 

strings,  it 

o 

function  (X,  Y : STRING)  return  STRING  is 

S : STRING (l  ..  X' LENGTH  ♦ Y' LENGTH); 

begin 

S(1  ..  X' LENGTH)  :«  X; 

S(X* LENGTH  + 1 ..  S' LAST)  :*  Y; 

o 

return  S; 
end ; 

c 

o 

3.7  Record  Types 

o 

o 

A record  object  is  a structure  with  named  components.  A record  type  definition  can  include  a 

variant  part 

o 

o 

denoting  alternative  record  structures. 

o 

Syntax : 

o 

•record_tyoe_def init ion 

o 

record  “ 

component's 

o 

u 

end  record  * 

o 

components  :s» 

{object__declaration}  fvar  iant_pert)  1 null; 

o 

vacinnt_part  :?■ 

o 

case  discriminant  of 

o 

{when  choice  {1  choice)  *> 

o 

component_sj 

end  case; 

c 

discriminant  constant  component  name 

o 

U 

Abstract  Syntax: 

o 

comp  s ->  COMP  ...  — f record  COMP  ...  end  record) 

variant  part  ->  NAME  VARIANT  S — [case  NAME  of  VARIANT  SI 

c 

o 

variant  s ->  VARIANT  ...  — [variant  ...J 

variant  ->  CHOICE  S COM?  S — [when  CHOICE  S ->  COMP  SI 

o 

o 

COMP  dccl  I null  I variant  part 

VARIANT  s : * variant  s 

VARI.Mt  :•*  variant 

Dcscr ipt ion* 


The  components  of  a record  ace  defined  by  object  declarations.  Components  can  be  of  different  types.  The 
value  of  an  expression  provided  as  a component  initialisation  is  evaluated  when  the  record  type  definition  is 
elaborated.  This  value  is  used  to  initialize  the  cor resoonding  component  for  every  record  declared  of  this 
type. 
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Recursion  In  record  type  definitions  Is  not  allowed  unless  an  Intermediate  access  type  is  used  (see  3.B). 


O 

c 


I o 

i o 

I o 

i 

J 

j o 


3.7.1  Constant  Record  Components  and  Discriminants 


A constant  component  of  a record  which  is  not  given  an  explicit  value  in  the  type  definition  is  a deferred 

constant.  Such  a deferred  constant  can  only  be  assigned  by  means  of  a complete  record  assignment. 

A record  component  can  be  a dynamic  array  only  if  the  bounds  that  are  not  static  are  deferred  constant 

components  of  the  record  type,  a deferred  constant  component  used  in  this  way  or  in  a variant  part  is  called 

a discriminant  of  the  record  type. 

The  only  permissible  dependencies  between  record  components  are  the  dependencies  of  an  array  bound  and  of  a 
variant  on  a discriminant. 


3.7.2  Variant  Parts 


A record  type  with  s variant  part  specifies  alternative  record  components.  Each  variant  defines  the 
components  for  the  corresponding  value  of  the  discriminant . A variant  can  have  an  empty  component  list,  which 
must  be  specified  by  null. 


o 


; o 
i o 

i 

! O 


3.7.3  Record  Aggregates  and  Discriminant  Constraints 


An  aggregate  Is  used  to  provide  values  for  all  the  components  of  a record.  In  an  aggregate  for  a record 
variant,  the  discriminant  value  must  be  a static  expression  and  must  appear  before  the  values  for  the 
corresponding  components  of  the  variant  part. 

discrimin*nt_constr*int  aggregate 

A discriminant  constraint  is  used  to  constrain  discriminants  of  a record  to  specific  values?  it  is  expressed 
as  an  aggregate  specifying  values  for  discriminants  only.  Discriminant  constraints  may  be  used  to  define 
subtypes  of  record  types  with  variants. 


3.8  Access  Types 


Objects  declared  in  > orogram  are  accessible  by  their  name.  They  exist  during  the  lifetime  of  the  declarative 
part  to  which  they  ar*  local.  in  contrast,  objects  may  also  be  created  dynamically  by  the  execution  of 
cl  1 orators  (see  ‘'.7).  gince  they  do  not  occur  in  an  explicit  object  declaration,  they  cannot  be  designated  by 
their  n-'Tie.  Instc*--'4,  '»cccss  to  such  an  object  is  nrMovod  by  ?n  access  value  returned  by  an  allocator. 

Syntax; 

occnss_typc_dof i ni t ion  access  type 


r\ 


c • 


o ! 

I 

o ; 


o 


o 


o 
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Abstract  Syntax ; 


access  ->  TYPE 


Description: 


— (access  type] 


An  access  type  definition  characterizes  a set  of  access  values  which  may  be  used  to  designate  objects  of  the 
type  mentioned  after  the  reserved  word  access.  This  type  cannot  be  another  access  type.  The  dynamically 
created  objects  designated  by  the  values  of  ah  access  typo  form  a collection  implicitly  associated  with  the 
type.  An  access  value  obtained  from  an  allocator  can  bo  assigned  to  several  access  variables.  Hence  a given 
dynamically  created  object  may  be  designated  by  more  than  one  variable  or  constant  of  the  access  type.  The 
access  value  null  belongs  to  every  access  type  and  designates  no  object  at  all.  It  may  be  used  to  initialize 
access  variables. 

An  object  of  an  access  type  that  is  introduced  as  a constant  cannot  have  its  value  changed,  nor  can  the  value 
of  the  designated  object  be  changed.  Such  an  access  object  can  only  be  used  in  an  expression  or  as  an  in 
parameter;  it  cannot  be  assigned  to  an  access  variable  (otherwise  the  designated  object  could  be  modified 
using  the  variable). 

Constraints  specified  for  an  access  type  apply  to  the  type  of  the  designated  objects.  Oual i f icat ion  of  an 
expression  of  an  access  type  applies  to  the  designated  object. 

Although  the  dynamically  created  objects  nay  not  be  of  an  access  type,  there  is  no  restriction  on  their 
components.  Thus,  components  of  the  object  designated  by  the  values  of  an  access  type  may  be  values  of  the 
same  or  of  another  access  typo.  This  permits  recursive  and  mutually  dependent  access  types  (whose  declaration 
requires  a prior  incomplete  type  declaration  for  one  or  more  types). 
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o 


4.  Names,  Variables,  and  Expressions 


o 


o 

o 

o 

o 

o 

o 


4.1  Names 

Names  denote  declared  entities  such  as  variables,  constants,  types,  end  program  units. 
Syntax : 
name 

identifier  I indexed_component 

I selected__component  I predef ined_ attribute 

indexed^ component  name (expression  {,  expression}) 

selected_component  name  . identifier 

predef ined_ attribute  name  ' identifier 


o 

o 

o 


Abstract  Syntax: 

id  -> 

Tndcxed  ->  NAVE  EXP  S 

predefined  ->  NAVE  ID 

Selected  ->  NAME  ID 


t lexical  unit) 
( NAME (EXP  S)  ) 
{ NAME1 ID  1 
j NAME. ID  1 


NAME  all  I ii}  I Indexed  I predefined  I selected  I slice 
Description; 

The  simplest  form  for  the  name  of  »n  entity  is  the  identifier  given  in  its  declaration. 


Static  Semantics: 

CHECK_NAME(name:  TREE:  type_den:  S TYPE  DEN;  env:  S EHV)  return  TREE  Is 
begin- 

case  xiND(name)  of 


when 

ail  *> 

CHECK  ALL 

(name , 

type  den, 

env)  ; 

when 

vr  -> 

CHECK  ID 

(name , 

typ-  den. 

env)  j 

when 

Indexed  *> 

CHECK  INDEXED 

(name , 

type  den, 

env)  : 

when 

predefined  *> 

CHECK  PREDEFINED 

(name , 

typ"  den, 

env)  ; 

when 

selected  *> 

CHECK  SELECTED 

(name , 

tyoe  den, 

env)  ; 

when 

slice  *> 

CHECK  SLICE 

(name. 

type_^den, 

env)  : 

o ! 


o ; 

i 

O ! 

j 

O I 

I 


o j 


Vw  ; 
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end  case; 

end  CHFCK  NAME; 


function  CHECX_ID(id:  TREE ; type_den:  S TYPE  DEN ; env:  5 ENV)  return  TPEE  is 
begin 

if  INCOMPATIBLE  ( type_den , TYPE_DEN_of ( id , env))  then 
return  id; 
else 

return  ID_INCOMPATIPLE_WITH_TYPE; 
end  if; 
end  CHECK  ID; 


4.1.1  Indexed  Components 


Descr  i r> t i on  : 

An  indexed  component  can  denote  either 

(a)  A component  of  an  array: 

The  name  identifies  the  array,  (or  an  access  object  whose  value  designates  the  array,  see  3.8)  and  the 
expressions  give  the  indices  for  the  component.  If  the  array  has  more  dimensions  thar  the  given  number 
of  expressions,  the  array  component  is  a subarray  of  the  named  array. 

(b)  A task  in  a family  of  tasks: 

The  name  identifies  the  task  family  and  the  expression  (only  one  can  be  given)  specifies  the  index  of  the 
Individual  task. 


(c)  An  entry  in  a family  of  entries: 

The  name  identifies  the  entry  family  and  the  expression  (only  one  can  be  given)  specifies  the  index  of 
the  individual  entry. 

If  evaluation  of  one  of  the  expressions  gives  an  index  value  that  is  outside  the  range  specified  for  the 
index,  the  exception  INDEX^ERROR  is  raised. 

Static  Semantics: 

function  CHECK_INDEXED( indexed:  TREE;  type_den:  S TYPE  DEN;  env:  S ENV)  return  TREE  is 
den  : constant  S DEN  :■  DEN  OF  (NAME ( indexed)  , env); 

name_type:  constant  S TYPE  DEN  :*  TYPE_DEN (den) ; 

begin  “ 

if  IS  ARRAY (namc_type)  and  IS  COMPATIBLE (type  den,  COMPONENT  TYPE (name  type)) 

then  return  MAKE  ( indexed , NAME ( indexed) , CHECK  INDEXES  (EXPJ?  ( indexed) , type_den,  env)); 
elsif  TS_ACCESS (name_type)  then 
declaTe 

n*me_typel:  constant  S_TYPE_DEN  :*  OBJECT_TYPE (nnme_type) ; 

begin  “ 

if  IS_ARRAY(namc_type)  and  IS_COMPATIBLE ( type_don , COMP0NENT_TYPE (name  type!)) 

then  return  MAKE  ( indexed*,  NAME  ( i ndexed)  , f“ECK_TMr*F.X_/'’ (EXP_S  ( i ndexeF)  , ►ype_dr'n,  env) 
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o 

o 

o 

o 

o 

o 

o 

o 

o 


c 


a 

o 

o 

o 


else  return  INDEX  TYPE  INCOMPATIBLE; ; 
end  If; 
end; 

elsif  IB  TASK (name  tyoe)  then 

tf  iS~ALONE (EXP~Si indexed) ) then 

return  CHECK  TASK ( indexed , type  den,  env) ; 
else  return  ONL?  CMC  EXP  ALLOWED;  “ 

end  If: 

elsif  IS  ENTRY (name  tyoe)  then 

if  I S~ALONE(EXP_S< indexed ) ) then 

return  CHECK  ENTRY  FAMILY (indexed,  type  den,  env); 
else  return  ONLY  ONE  Tndfx  ALLOWED;  ~ 

end  if: 

else  return  TYPE  INDEX  NAME  INCOMPATIBLE; 

end  if; 

end  CHECK_TNDEXED; 


4,1,2  Selected  Components 


Description: 

A selected  component  can  denote  either 

(a)  A component  of  a record: 

The  name  identifies  the  record  (or  an  access  object  whose  value  designates  the  record)  and  the  identifier 
specifies  the  record  component. 

(b)  An  entity  declared  in  the  visible  part  of  a module: 

The  name  identifies  the  module  and  the  identifier  specifies  the  declared  entity. 

(c)  An  entity  declared  in  an  enclosing  unit: 

The  name  identifies  the  enclosing  unit  and  the  identifier  specifies  the  declared  entity. 

(d)  A user-defined  attribute  of  a type: 

The  name  identifies  the  type  and  the  identifier  specifies  a user-defined  subprogram  attribute  of  the  tyoe 
(see  3.3) . 

For  variant  records,  a component  identifier  can  denote  a component  in  a variant  part.  In  such  a case,  the 
selected  component  must  belong  to  the  variant  prescribed  by  the  discriminant  of  the  record,  otherwise  the 
exception  DISCRIMINANT_ERROR  is  raised. 

Stat ic  Semantics: 

function  CHECK_INDEX  S (exp  s:  TREE;  type  den:  S TYPE  DFN;  env:  S ENV)  return  TRrp  Is 
begin 

if  IS  EMPTY (exp_s)  then  return  void; 
else  Tf  IS  ARRAY (type  den)  then 

return  ?RF (CHECK_EXP (HFAP(cxp_s) , INDFX_TYPE ( typc_den) , env). 


O ' 

i 


O 

o 


o 


o 
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i n 

l 

i ’ ^ 

\ o 

; ° 
o 


CHECK  INDEX  S(TML(rxp_3), 
IS_ VOID ( type_ cfrn)  tfien 


COMPONENT  TYPE ( tyoc  don), 

«l8lf  _ - 

return  INC0MPATT3LE_TYPE ; 

else 

return  PKE (CHECK  EXP(HEAD(exp  s)  , type  den,  env); 

end  i f ; 

end  CHECK  INDEX  S; 


4.1.3  Predefined  Attributes 


env) ) ; 


Poser irt ion; 

For  user-defined  attributes,  as  explained  above,  the  notation  of  selected  components  is  used;  the  named  entity 
is  s type,  and  the  attribute  identifier  is  a subprogram  provided  by  the  user.  For  predefined  attributes,  the 
apostrophe  notation  is  used;  the  named  entity  need  not  be  a type  and  the  attribute  identifier  in  predefined  in 
the  language.  A predefined  attribute  identifier  is  always  prefixed  by  an  aror.r rophe , hence  thesn  identifiers 
are  not  reserved.  Specific  predefined  attributes  are  described  with  the  cor  respond i ng  language  constructs. 


Appendix  A gives  a list  of  all  the  language 
for  an  implementation. 


predefined  attributes.  Additional  predefined  attributes  may  exist 


C ; 

I 

I 

C ; 

° ! 

| 

O ; 
O ; 


o 

* • 

o 

Static  Semantics:  *'  , 

o 

o 

• o 

1 

4.2  Literals 

c 

o 

A literal  denotes  an  explicit  value  of  a given  type. 

o 

Syntax : 

o 

literal  ::* 

number  1 enumerat ion_l i teral  1 character  string  I 

null 

c 

° 

Abstract  Syntax: 

G 

c c 

int  number  ->  — [ lexical  unit  ] 

real  number  ->  — f lexical  unit  1 

->  — [ lexical  unit  j 

string  ->  — [ lexical  unit  1 

nu 1 \ ->  — [ null  ] 

G 

Informal  Semantics: 

A number  or  an  enumerat' ion  literal  denotes  a .value  of  the 
designates  no  object  at  all.  Literals  for  approximate 
context  in  which  they  are  us^d. 

corresponding  scalar  type, 
numbers  are  rounded  to  the 

The  access  value  null 
precision  required  by  the 

Formal  Definition  - & 
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* 

procedure  CHECK^LITERAL (literal:  TFEE ; type_dcn:  s TYPE  PEN?  cnv:  s ENV)  return  TREE  is 
begin  ~ 

if  INVALID  LITERAL  (1  iter  el , type_den,  env)  then 
return  literal; 
else 

return  LITERAL  INCOMPATIBLE  WITH  TYPE; 
end  if; 

end  CHCCK_LTTERAL; 

procedure  IS_VALID  LTTEPAL(literal:  TREE;  type  dor:  S TYPE  PE N;  env:  S ENV)  return  BOOLEAN  is 
begin 

case  KIND ( 1 i tcral ) of 

when  i nt  number  =>  return  IS— INTEGER ( typc_den) ; 
when  r e 7 1 number  ■>  return  lS-FEAL(typc  den); 

when  ■>  return  IS-VALTC_ENUMERATTON ( 1 i tcral , type_den,  env); 

when  string  *>  return  IS  STRING ( type  d^n)  or  CHARACTER ( 1 i teral ) and 

IS_VALID_FNUMERATIOW (literal , typ?_den , cnv); 
when  nul 1 =>  return  IS_ACCESS (type_den) ; 

end  case; 

end  IS_VALID_ LITERAL; 

procedure  IS_VALID  ENUMERATION (literal:  TREE;  type  den:  S TY*>e  DEN;  env:  S ENV)  return  BOOLEAN  is 
begin 

return  IS  COMPATIBLE ( type__den , TYPE  OF(literal,  env)); 
end  IS  VALID- ENUMERATION ; 


Dynamic  Semantics: 

procedure  EVAL_LITERAL (literal:  TREE;  env;  D ENV;  cont:  EVAL  CQNT)  return  EXEC  CONT  is 
begin 

return  cont(VAL  (literal)); 
end  EVAL_LITEP.AL; 

procedure  VAL(literal:  TREE)  return  VAL  is 
begin 

— maps  literal  to  an  abstract  value 
end  VAL; 


4.3  Variables 


A variable  is  an  object  of  an  arbitrary  type  whose  value  can  be  changed.  A variable  can  be  a scalar,  an 
array,  a record,  or  an  access  object.  Alternatively,  it  can  be  a component  of  another  object  or  a slice  of  an 
array. 

Syntax : 

variable  name  ( (discrete_range) 1 I name. all 


Formal  Definition 


4 - 5 


Prel Jminary  Draft 


Abstract  Syntax : 


all  ->  NAME  [NA^E.all] 

FTTcc  ->  NAME  RANGF  [NAVE  (RANGE) 1 

NAME  a)  1 I _i_d  | indexed  | predef  ined  | selected  I si  ice 

When  a name  is  followed  by  a discrete  range,  the  name  must  be  the  name  of  an  array  (or  subarr»y)  or  of  an 
access  object  whose  value  designates  an  array.  The  range  "ust  denote  a contiguous  sequence  of  index  values 
for  the  first  dimension  of  the  array  (or  subarray) . Such  a variable  is  celled  an  array  slice.  Its  type  is 
that  of  the  array,  with  the  constraint  given  by  the  discrete  range.  For  names  of  access  objects  with  the 
qualifier  all,  the  variable  denotes  the  entire  object  designated  by  the  access  value. 


4.4  Expressions 


An  expression  is  a formula  that  defines  the  computation  of  a value. 
Syntax : 

expression  : : ■ 

relation  {and  relation) 

I relation  {or  relation) 

I relation  (xor  relation) 

relation 

simclc_cxprcs*5ion  { r el  at ionel_oper ator  simple_expr  ess  ion) 

I simp] c_exprcssion  {not)  in  range 
I simple~expression  (not)  in  type_mark  [constraint) 

simple_expression  (una ry_opcrator J term  { adding_opcrator  term) 

term  factor  {multiply ing_operator  factor) 

factor  primary  {**  primary) 

primary 

literal  I aggregate  I variable  I allocator 
I subprogram_call  I goal  if ied_expr ession  1 (expression) 

Abstract  Syntax; 

exp  s ->  EXP  ...  — ( EXP  , ...  ) 

F.XP  binary  I unary  I membership 

I int  number  I r^al  number  I str i ng  1 nul 1 I aggregate 

I NAME  I .S1  locator  I c^l  1 I cue  1 i f ieo 

FXP  LIST  oxo  s 

TYPE  RANGE  : : * constrai ned  | pair  I typed  pair 
Descr lotion; 
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Primaries  include  constants  and  predefined  attributes,  which  arc  covered  by  the  syntactic  category  "variable". 
An  expression  of  a given  type  is  also  regarded  as  a one-component  aggregate  for  a corresponding  .array  or 
record  type.  The  type  of  an  expression  depends  on  the  typ-  cf  its  constituents,  as  described  below. 


Static  Semantics ; 


n 


o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 


procedure  Ct'ECK_EXP  (exp:  TREE;  tyne_deo:  S TYPE  PE’1;  "nv;  s_ 
oxp2:  constant  TPEE  :*  NORMALIZE-EXP (exp,  type  den,  cnv|  ; 

begin 

1C  KTN0(cxp2)  * jjl  and  not  IS_ENUMERATION  (type— den)  then 
return  CHECK  NAME  (exp2,  type_den,  env) ; “ 
elsif  TF_LITEPAL(cxp2)  then 

return  CHECK  LITEFAL(oxp2,  type  den,  env); 
elsif  ls_:iAVE(cxp2)  then 

return  CHCCK_MAME  (exp2,  type_den,  env); 
else 


ENV)  return  TREE  Is 


when 

binary 

«> 

return 

CHECK 

BINARY 

(exp2, 

type_den. 

env) 

when 

unary 

-> 

return 

CHECK 

"unary 

(cxp2. 

type_den , 

env) 

when 

nicmb-'.  r sh ip 

■> 

return 

CHECK 

■"membership 

(oxp2 , 

typo^den , 

env) 

when 

comp  assoc 

s -> 

return 

CHECK 

"aggregate 

(px?2  , 

typo^d^n , 

env) 

when 

a ) loca  tor 

■> 

return 

CHECK 

"allocator 

(exp2, 

typo^den , 

env) 

when 

call 

«> 

return 

CHECK 

"call 

(cxp2 , 

typn”dcn , 

erv) 

when 

our  1 i f i nd 

-> 

return 

CHECK_QUALIFTE0 

(cxp2. 

typo^den , 

env) 

end  If; 

end  CHECK  EXP; 


procedure  KOPMALIZE_CXP  (exp:  TREE;  type_den:  S TYPE  DEV;  'env:  S ENV)  return  TREE  is 
begin  — discovers  one-component  aggregates 

if  IS_ARRAY ( tyne_den)  and  IS_VALID  ARRAY  COMD(cxp,  type  den,  env) 
return  PRE (MAKS (come  assoc,  cxpT,  EMPTY); 
el9if  IS_RECOREi(typo_drn)  and  I RIVALED  KECORD_CCMP (exp,  type_dcn,  env) 
return  PRE (Make'(cqtip  assoc,  exp),  EMPTY); 
else 

return  exp; 
end  if; 

end  NORMALIZE  EXP; 


procedure  IS  valid  EXPtcxp:  TREE;  type  den:  ? type  PFH;  »nv:  s FNV)  return  nOOLEAN  is 
exp2:  constant  TREE  : ■>  NORMALIZE  EXP(exp,  type_c'en,  env); 

begin 

if  KIND (exp2 ) - _id  and  not  IS_ENUMEPATlON(typc_den)  then 
return  IF  VALID  name  (exp2,  typc_den,  env); 
elsif  TS_LITERAL(exp)  then 

return  IS_VALTD  LITERAL (exp2 , type  den,  rnv) ; 
elsif  IE_NA”f (exr2T  then 

return  IS  VALID  NAME  (exp2,  type_den,  env); 
else 

case  KlND(exp2)  of 

when  UnTy  =2  return  IS  V"LT!5  eTNARv  (r>e?,  type_den,  env); 


O 
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when  unpry  *>  return  lS_VALTD_U\’AnY  (exp?,  type^den,  env); 

when  m^-v-^rsh  i o «*>  return  IS^SOOLEAN  (type_den);~ 

when  • -y-r  «>  return  TS~vALTP_AGoF.ECATE  (exp27typo_dcn  ,env)  ; 

when  - \ i - tor  *>  return  Is7VRlLID_ALL0CATCR  (exp?  , typr_den,  cr.v)  ; 

when  cM ) * *>  return  IS^V^LID^CALL  (exp?,  typc~dcn,  env); 

when  cu-  1 i f i r»d  »*>  return  IS^VALTD^OUALIFIED  (exp?  , typc"”dcn,  env); 

end  case; 
end  if; 

end  IS_VALID_rxp2; 

procedure  TS  VALID  ARRAY  COMP  (exp:  TREE;  array  tyoc  den:  s TYPE  DEN;  env*.  S EFV)  return  OOOLFAN  is 
begin 

--  returns  true,  if  the  expression  is  of  a type  compatible  with 
--  that  of  the  components  of  the  army  type. 

end; 

procedure  IS_VALID_RFCORD_COMP  (exp:  TREE;  type_den:  R TYPF,  PS**;  env:  S FNV)  return  POOLFAN  is 

begin 

— returns  true,  if  the  expression  is  of  a type  compatible  with 
--  that  of  the  (unique)  component  of  the  record_tyoe^den . 
end; 

procedure  I5_LITFPAL (exp:  TREE)  return  POQLFAM  is 
begin 

case  KIND(exp)  of 

when  irt  number  | real  number  I _icl  I string  I null  *>  return  true; 
when  others  *>  return  false; 
end  case; 
end  f r,  LITER* Li 


Dynamic  Semantics: 


procedure  EVALJ2XP (exp:  TREE;  env:  P ENV;  cont:  EVAL  CONT)  return  EXEC  CONT  is 
begin 

if  IS  LITERAL ( exp)  and  K f ND (exp)  /■  id  then 
return  EVAL  LITEP*L(oxp,  cont): 
elsif  I«_VAVE(exp>  then 

return  EV\L_name (exp,  env,  cont); 

else 

case  KIMD(oxp)  of  — binary  and  unary  expressions  have  been  normalised  to  calls 
when  m^brr ship  *>  return  FVAL_*FMnFPSHT p (^xp,  env,  cont); 
when  rigrn-r-tr  ■>  return  FV'L7''G0Ppr"TP  (exp,  ~nv,  cont); 

when  a) locator  •>  return  EV.AL~ALL0CA70R  (oxp,  env,  cont); 

when  ca] j »>  return  FVAL~C*LL  (exp,  env,  cont); 

when  cur  1 i f ie*  •>  return  FV*l79U*LI  rt  Ef>  («»xp,  «nvj  cont); 

end  case; 
end  if; 
end  FVAL  EXP; 


4.5  Operators  ard  Expression  Evaluation 
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The  operators  in  the  language  are  grouped  into  six  classes,  given  in  the  following  order  of  increasing 
precedence: 


Informal  Semantics: 
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For  a sequence  of  operators  of  the  same  precedence  level,  evaluation  proceeds  in  textual  order  from  left  to 
right,  or  in  any  order  giving  the  same  result.  The  primaries  of  an  expression  are  also  evaluated  in  textual 
order.  All  primaries  are  evaluated  and  all  operations  are  performed. 

The  operands,  result  types,  and  the  meaning  of  the  predefined  operators  are  given  below.  Koto  that  some 
operations  may  result  in  exception  conditions  for  some  values  of  the  operands  (see  chanter  11).  Real 
expressions  are  not  necessarily  calculated  with  exactly  the  specified  accuracy  (precision  or  delta),  but  the 
accuracy  used  will  be  at  least  as  good  as  that  specified. 

Static  Semantics: 

procedure  CHECK  BINARY (binary : TREE;  type  den:  S TYPE  DEN;  env:  S FNV)  return  TREE  is 
param_ossoc  s:  constant  TREE  :»  PRE  “(EXPlIbinary) , PPE (EXP2 (binary) , EMPTY)); 
ext_name  ” : constant  TfcEE  :»  OP_NAME (BINARY_OP (bi nary) ) ; 

begin  " 

return  CHECK_CALL2 (ex t_name , param  assoc_s,  type  den,  env); 
end  CHECK_B INARY; 

procedure  CHECK_UNARY (unary:  TREE;  type_den:  S TYPE  PEN;  env:  S FNV)  return  TREE  is 
param  assoc  s:  constant  TFEE  :*  PRE  “ (EXP(unary),  empty): 
ext_name  “ : constant  TREE  :*  OP_NAME (UNAPY_OP (unary )) ; 
begin 

return  CHECK  CALL2(cxt  name,  param_assoc_s , type_den,  env); 
end  CHECKJJNAPY7 

procedure  CHECK_MEMPFPSHIP (membership:  TREE;  type  den:  S TYPE  DEN;  env:  S ENV)  return  TREE  is 
troo_type_ den:  constant  TPEE  S TYPE  PEN  :■  CHF^K^ TYPE_PANGE (TYPE_RAKGC (rremborsh i p) , env); 
exp  : constant  TREE  :-  CHECk”exp  (EXP (member sh ip) , TYPE(tree  type_den) , env); 

begin 

If  r SCHOOL CAN (type  den)  then 

return  tfAXE (mcmBership,  exp,  MSMBERSHIP_OP (membership) , TREE ( tree_type_dcn) ) ; 

else 

return  MEMBERSHIP  EXPRESSIONS  HAVE  TYPE  BOOLEAN; 
end  if;  ” “ 

end  CH£CK_ MEMBERSHIP; 

procedure  CHECK_TYPE_RANGE ( type_range:  TREE;  env:  S ENV)  return  TREE  S TYPE  DEN  is 
begin 

case  KIND(type  range)  of 

when  constrained  ■>  --  ( NAME  COMSTPftTNT  ] 

return  CHECK  CONSTRAINED ( typc_range , env); 
when  pair  — ( EXP  . ."EXP  ) 

I tyood  pair  *>  — ( N*MF  range  FXP  , . FXP  1 

declare 

typo  den  : constant  5 TYPE  PEN  »■  TYPE_OF  (type_range,  ertv)  ; 

typoB_pair  : constant  TREE  :*  CHECK  RANGE ( type“range,  type_den,  env); 

begin  ” 

return  TREE  TYPE (MAKE (constra i ned , NAME ( typed_pair) , PAIR ( typed_pa ir ) , typc_den) ; 

— a range  Is  normalized  into  a constrained  type_dcn. 
end; 

end  case; 

end  CI!£CK_TYPE_JRANGE ; 

The  definitions  of  the  predefined  operationss  are  given  in  Appendix  C. 


O j 

O 

O 

O 

O 

o 

o 

o 

o 

o 

o 

o 


Formal  Definition  1-10 


Preliminary  Draft 


X. 


Q 


r> 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 


Dynamic  Semantics: 

Binary  and  unary  expressions  have  been  normalized  into  procedure  calls. 

procedure  EVAL_ MEMBERSHIP  (membership:  TREE;  env:  n rw?  cont:  rvAL  CON T)  return  rxrc  CONT  Is 
— tests  constraints  for  type  or  subtype  membership. 

Dynamic  Scmant ics : 

procedure  RVAL  CALL  (call:  TREE;  env:  D ENV;  cont:  EVAL  CONT)  return  rxsc  CONT  is 
procedure  C0NTTNUE1  (parm^vr l_s:  P.^nyi  v^L  return  rxrc  CO^t  is 
don:  constant  D PCM  : »~DEN“CP (ID (cal  1) , rnv) ; 
procedure  C0NTINUE2 (val : val)  return  EXEC  COVT  is 
tyoe^den:  constant  0 TYnE  DP*?  :■  RTSULT (d^n)  ; 
ex_env  s constant  EX  env  :*  EX_ ENV(rnv); 

begin 

if  IS_FANC5E_ERP0R  (val  , type_dcn)  then 
return  cx_^nv  (RAfJGE_Epnnrt)  • 
elsif  IS_OVEPFLOW ( va 1 , typo  den)  then 
return  cx_cnv(val,  type_oen) ; 
else  return  cont(val);  ” 
end  if; 

end  CONTINUE 2; 

begin 

return  denfnaram  val  s,  CONTINUE?) ; 
end  CONTINUED  “ 

begin 

return  EVAL_PARAM  ASSOC  S (PARAM  ASSOC  S(call),  env,  CONTINUED; 
end  EVAL_CALL; 
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4.5.1  Logical  Operators 


O 


Logical  operators  are  applicable  to  boolean  values  a nd  to  one  dimensional  arrays  of  boolean  values  having  the 
same  number  of  components.  The  operations  on  arrays  are  performed  on  a component  by  component  basis. 


o 

Operator 

Operation 

Ooerand 

Type 

Result  Type 

r-\ 

o 

and 

conjunction 

BOOLFAM 

boolean 

array 

type 

BOOLEAN 

same  array  type 

o 

or 

inclusive  disjunction 

BOOLEAN 

boolean 

ar  ray 

type 

BOOLEAN 

same  array  type 

o 

xor 

exclusive  disjunction 

BOOLEAN 

boolean 

array 

type 

BOOLEAN 

same  array  type 

4.5.2  Relational  and  Membership  Operators 
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The  relational  operators  have  operands  of  the  same  typo  *n^  return  boolean  values.  Note  that  eouality  end 
inequality  ace  defined  foe  any  two  objects  of  the  saTe  type  (unless  the  type  is  a restricted  type,  see  7.4). 


Operator  Operation 

• /■  equality  and 

inequality 


Operand  Type  Posul t Type 
any  type  BOOLEAN 


< <■  test  for 

> >•  ordering 


any  scalar  ROOLEAV 

type 


Equality  for  the  discrete  types  is  eouality  of  the  values.  For  a floating  (or  fixed)  point  type  T,  if  two 
values  differ  by  less  than  T' SMALL  (or  T' DELTA) , then  the  result  delivered  by  a relational  operator  is 
implemcntat ion  defined.  Equality  for  array  and  record  types  In  equality  of  the  components,  as  given  by  the 
predefined  operators.  Hence,  this  operation  is  unchanged  by  any  redefinition  of  equality  on  the  component 
types  involved.  Two  access  values  (see  3.8)  are  equal  if  they  designate  the  same  dynamically  allocated 
object . 


The  inequality  operator  gives  the  complementary  result  to  the  equality  operator. 

The  membership  operators  in  and  not  in  test  for  membership  of  a value  of  any  type  within  a corresponding 
range,  subtype,  or  constraint.  These  operators  return  a boolean  value  and  have  the  same  precedence  as  thr 
relational  operators. 


4.5.3  Adding  Operators 


The  adding  operators  ♦ and 
Operator  Operation 
♦ addition 

- subtraction 

6 catenation 


return  a result  of  the  same  type  as  the  operands. 

Operand  Type  Result  Type 

numeric  type  same  numeric  type 

numeric  type  same  numeric  type 

one  dimensional  same  array  type 

array  type 


For  real  types,  the  accuracy  of  the  result  is  the  accuracy  of  the  operand  type. 

The  adding  operator  & (catenation)  Is  applied  to  two  operands  of  an  array  type  which  has  been  declared  to  be 
one  dimensional  and  whose  index  is  specified  by  a type  mark.  The  result  is  an  array  of  the  same  type.  (Note 
that  an  expression  of  the  component  type  is  regarded  as  a one  component  array  of  this  type) . For  strings,  this 
operation  results  in  conventional  string  catenation. 

For  all  numeric  types,  the  exception  RANGE_ERROR  is  raised  if  the  result  value  is  outside  the  range  of  the 
result  type.  The  exception  OVERFLOW  is  raised  if  the  result  value  is  beyond  the  implemented  limits. 


4.5.4  Unary  Operators 
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Unary  operators  are  applied  to  «*i  single  operand  and  return  a result  of  the  same  type. 


Operator  Oper  at  Ion 
t identity 

- negation 


Operand  Type 
numeric  type 
numeric  type 


Pesult 


Type 


not 


logical  negation  BOOLEAN 


same  numeric  type 
same  numeric  type 
BOOLEAN 


boolean  array  type  same  array  type 


The  operator  not  can  also  be  applied  to  arrays  of  boolean  values  on  a component  by  component  basis,  just  as 
for  logical  operators. 

The  exceptions  RANGE_ERROR  and  OVERFLOW  can  be  raised  by  the  negation  operation,  just  as  for  th«  subtraction 
operation . 

4.5.5  Multiplying  Operators 

The  operators  * and  / for  integer  and  floating  point  values  and  the  operator  mod  for  integer  values  return  a 
result  of  the  same  type  as  the  operands. 


Operator  Operation 
* multiplication 


Operand  Type  Result  Type 


/ 

mod 


integer 

floating 


integer  division  integer 
floating  division  floating 


modulus 


integer 


same  integer  type 
same  floating  type 

same  integer  type 
same  floating  type 

same  integer  type 


Integer  division  and  modulus  are  defined  by  the  relation 
A - ( A/B)  *B  4-  (A  mod  B) 

where  (A  mod  B)  has  the  sign  of  A and  an  absolute  value  less  than  the  absolute  value  of  B.  Integer  division 
satisfies  the  identity 

(-A1/B  - -(A/B)  - A/(-B) 

For  fixed  point  values,  the  following  multiplication  and  division  operations  are  provided.  The  types  of  the 
left  and  right  operands  are  denoted  by  L and  R . 


Operator  Operation 


Operand  Type 
L R 


Resul t Type 


multiplication  fixed  integer  same  as  L 

integer  fixed  same  as  P 

fixed  fixed  universal  fixed 


C | 

i 

O I 

i 
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:tr 


division 


f ixcd 
fixed 


J ntcger 
fixed 


fame  as  L 
universal  fixed 


n 


/ 


r\ 

O 

O 


o 


Integer  multiplication  of 
operation.  Division  of  a 


fixed  point  values  is 
fixed  point  value  by  an 


equivalent  to 
integer  does 


repeated  addition  and 
not  involve  a change  in 


hence  is  an  accurate 
type  but  is  aoprox imate . 


Fixed  point  multiplication  may  yield  a value  of  an  arbitrary  accuracy  (denoted  by  universal  fixed  in  the 
table).  The  result  must  be  qualified  (see  1.6)  to  ensure  that  the  accuracy  of  th«  corput'tion  is  explicitly 
controlled.  The  same  considerations  apply  to  division  of  a fixed  point,  value  by  another  fixed  point  value. 


All  multiplying  operations  can  raise  the  exceptions  RANGE  rRPOR,  OVERFLOW,  or  UNDERFLOW.  Th<°  operations  / and 
mod  give  the  exception  DIVIDF._ERPOR  when  the  right  operand  is  zero. 


r- 

O 

C 
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4.5.6  Exponentiating  Operator 
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Operator  Operation 
**  exponentiation 


Operand  Type 
L R 


integer  positive  integer 
floating  integer 


P^sul t Type 

same  as  L 
same  as  L 


Exponentiation  of  an  operand  by  a positive  exponent  is  equivalent  to  repeated  multiplication  (as  indicated  by 
the  exponent)  of  the  operand  by  itself.  For  a floating  operand,  the  exponent  can  be  negative,  in  which  case 
the  value  is  the  reciprocal  of  the  value  with  the  positive  exponent.  This  operation  can  raise  thr*  OVERFLOW, 
DIVIDE^ ERROR , or  RAHGE_ERP.OR  exception. 


o 

o 
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4.6  Qualified  Expressions 


O 


o 

o 

o 

o 


Descr iot ion: 

A qualified  expression  is  used  to  state  the  type  of  an  expression  explicitly,  to  constrain  an  expression  to  a 
given  subtype,  or,  if  neither  case  applies,  to  convert  an  expression  to  another  type. 

Syntax: 

qual if ied_expression 

typejnark (expression)  I type_mark  aqgreqete 


O 

o 

c 


Abstract  Syntax: 

qualified  ->  MAME  EXP  — [ NAME  (EXP)  ) or  [ CAME  (COMP  ASSOC  S)  ) 
Static  Semantics: 
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procedure  CHECK  QUALIFIED (oual if  ? **d : TPEE ; type  den:  ? TYPE  DEN;  env:  SENV)  return  TPEE  is 
n*mc_typo_dcn;  constant  trbf  r>  TYPE  nEN  CMECKJTYPEJ*ARK  (NAME  (qua]  \ C ied)  . env)  ) ; 

begin  ” 

if  not  I S CO^PATTRLE (tyoo  den,  TYPE  DEN (tree  type  den))  then 
return“lNCOMPATIPLE_TYPEF ? 

elsif  I?  VALID  EXP (EXpTqusI i f led) , type  den,  env)  then  — - explicit  type  den  or  subtype_den  specification 
return  makeTpu.?! i f led,  NAME (nemc_type_den) , CHECK_EXP  (EXP (cu^lTf ied) , type_den,  env)); 

else 

return  MAKE (cual i f ied , NAME (name  type  den) , CHECK  CONVERSION (EXP (quail find) , type  den,  env); 
end  if; 

end  CHECK_ QUALIFIED; 

— The  function  IS_VALID_EXP  checks  that  the  expression  is  of  the  given  type. 

— It  is  defined  in  ChapTcr  6. 


Dynamic  Semantics; 

procedure  EVALJJUALIFTED (qual if iod s TREE;  env;  0 ENV;  cont;  EVAL  CONT)  return  EXEC  CONT  is 
name:  constant  TREE  :*  NAME  (ounl  i f ied)  ; 
exp  : constant  TREE  : * EXP  (qualified); 
den  ; constant  S DEN  ; »DEM  OF(narre,  env); 
procedure  CONTINUE (val ; VAL)  return  EXEC  CONT  ia 
begin 

case  KTNO(cxp)  of 

when  quel i f i ed  »>  — conversion  from  the  source  type  "NAME (exp) " to  the  target  type  "name" 
return  CONVERT(val,  den,  DEN_OP (NAME (exp) , env),  cont); 
when  others  ■>  — explicit  type^or  subtype  specification 
return  TEST_CONSTRATNT ( val , CONSTRAINT (den) , cont); 
end  case;  “ 

end  CONTINUE; 
begin 

return  EVAL  EXP(exp,  env,  CONTINUE); 
end  EVAL  QUALIFIED? 


4.6.1  Explicit  Type  or  Subtype  Specification 


The  same  literal  may  appear  in  several  types;  it  is  then  said  to  be  overloaded.  In  these  cases  and  whenever 
the  type  of  a literal  or  aggregate  is  not  known  from  the  context,  a qualified  expression  mu3t  be  used  to  state 
the  type  explicitly. 

In  particular,  an  overloaded  literal  must  be  qualified  in  a subprogram  call  to  an  overloaded  subprogram  that 
cannot  be  identified  on  the  basis  of  remaining  parameter  or  result  types,  in  a relational  expression  where 
both  operands  are  overloaded  literals,  or  in  an  array  or  loop  parameter  range  where  both  bounds  are  overloaded 
enumeration  literals. 

Explicit  type  specification  is  also  used  to  specify  the  result  type  of  fixed  point  multiplication  and 
division,  to  specify  which  one  of  a set  of  overloaded  parameter! ess  functions  is  meant,  or  to  constrain  a 
value  to  a given  subtype. 
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procedure  TES7_C0NSTRATNT ( val : VAL;  constrnint_val : CONSTRAINT  VAL;  contr  FVAL  CONT)  return  rvrc  CCNT  is 

begin  ” 

— test  that  the  value  "val"  satisfies  the  constraint  value  Mconstrrint_val " and  raises 

— appropriate  exception,  if  necessary. 

end;' 


4.6.2  Type  Conversions 


For  numeric  expressions,  a qualified  expression  may  specify  a numeric  type  that  is  different  from  the  type  of 
the  expression.  In  this  case,  the  value  of  the  expression  is  converted  to  the  named  type.  With  conversions 
involving  real  types,  the  converted  value  is  within  the  .accuracy  of  the  specified  type. 

Explicit  conversion  is  allowed  between  objects  of  derived  types.  The  conversion  may  result  in  a change  of 
representation,  as  described  in  chapter  13.  Explicit  conversion  is  also  allowed  between  array  types  if  the 
index  types  for  each  dimension  arc  the  same  or  derived  from  each  other  and  if  the  component  types  are  the  S3mc 
or  derived  from  each  other.  Conversion  involving  an  access  type  relates  to  the  type  of  the  accessed  objects. 

Static  Semantics:  . . 

procedure  CHECK_CONVEPSTON (exp:  TREE;  type_dcn:  S TYPE  DFN;  env:  S ENV)  return  TREE  is 
begin 

if  IS  NUMERIC (typc_dcn,  env)  then 

return  SOLVE_CONVEPSION (exp,  NUMERIC_TYPE_S (env)  , env); 
elsif  IS  ARRAY (type  den)  then 

return  SOLVE_CONVEPSTON (exp,  ARRAY_TYPE_S ( tyne_dcn , env),  env); 
elsif  IS  ACCFSsTtype  den)  then 

return  SOLVE^COHVERSION (exp,  ACCESS  TYPE_S ( type_dcn , env),  env); 
else  — conversTon  between  objects  of  derivable  types 

return  SOLVE  CONVERSTON (exp,  PRE (OLD  TYPE (type  den,  env),  DERIVED  TYPE  S(type  den,  env)),  env); 
end  if; 

end  CHECK_CONVERSION; 

procedure  NUMERTC_TYPE_S (env:  S ENV)  return  S TYPE  DEN  s is 
begin  " 

— the  list  of  all  visible  numeric  types 
end; 

procedure  ARRAY_TYPE_S  (type_den:  S TYPE  DEN;  env:  s__ENV)  return  S TYPE  DEN  s is 
begin 

— the  list  of  all  visible  array  types  to  which  the  given  type_den  may  be  converted 

end; 

procedure  ACCESS_TYPE_S  (type_den:  S TYPE  DEN?  env:  S ENV)  return  S_TYPF,_DEN_S  is 
begin 

— the  list  of  all  visible  access  types  to  which  the  nivon  type  den  may  be  converted 
end; 

procedure  SOLVE_CONVERSION (exp:  TPEE ; type_den_s:  S TYPE  DEN  S;  env:  S ENV)  return  TREE  is 
type-den__s2  :~constant  S TYPE  DFN  S :*  V^LIp”C'v',v^pr  Tnt’_?  (''xp,  typr*-cJon_r , env); 
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begin 

if  IS  EVnTY ( type  den  s2)  then 

return  INCOMPATIBLE  CONVERSION ; 
elsif  LENGTH  (type  den  7.2)  > 1 then 
return  A MP.  10 U0US_C0N VERSION; 

el9e  — the  source  type  den  of  the  conversion  is  inserted  in  the  result  » 

return  MAKE  (quel  i fi^,  ID  ( HEAD  ( tyoc  den  s2) ) , C«ECK  EXPfexp,  HEAD  (tyre  den  s2)  , env))  ; 

end  if; 

end  SOLVEJTONVFRSION; 

procedure  VALID_CONVFRSTCN_S (exp:  TREE;  type_dcn_S:  S TYPE  DEN  S;  env:  S ENV)  return  S TYPE  DEN  S is 

begin 

if  IS  EMPTY  ( tyoe_den_^s)  then 
return  EMPTY;”  ~ 

elsif  IS  VALID  EXP(exp,  HEAD ( type_den_s) , env)  then 

return  PRE (HEAD ( type_den_s) , VALIDJTONVEFSION_S (exp,  TAIL ( type_den_s) , env)); 

else 

return  VALID  CONVERSION  S(exp,  TML(type  den  s)  , env); 

end  if; 

end  VALIC_CONVEPSTON_S; 

--  IS_VALID_EXP  is  defined  in  Chapter  6. 

Dynamic  Semantics ; 

procedure  CONVERT(val:  VAL;  type_denl,  type_den2:  D TYPE  DEM;  conts  EVAL  CONT)  return  EXEC  CONT  is 

begin 

-•  Performs  conversion  from  source  type_den  "type_dcn2"  to  target  typc_dcn  "type_dcnl"  and 
- tests  appropriate  constraints 
end  CONVERT; 

4.7  Allocators 

An  allocator  specifies  the  dynamic  creation  of  an  object  and  the  generation  of  an  access  value  that  designates 
the  object. 

Syntax : 

allocator  new  qual ificd_expression 

Abstract  SYNTAX: 

allocator  ->  QUALIFIED  --  ( new  QUALIFIED  1 
QUALIFIED  ->  qual if i od 

The  object  created  by  the  allocator  is  initialized  with  the  value  of  ♦■he  expression,  which  is  qualified  by  the 
name  of  the  access  type. 

Static  Semantics: 
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procedure  CHECK_ALLOCATOR (al locator : TREE?  type  den:  r>  type  DEN;  envt  S ENV)  return  TREE  is 
qualified  “t  constant  TREE  :■  QUALIFIED  (allocator); 

name  : constant  TREE  :*  namf  (nullified); 

exp  : constant  TREE  :■  EXP  (qu*l i f i c'1)  ? 

trec_type_den:  constant  TREF  S TYPE  DEN  :*  C"ECK  TY°E__MARK  (nemo,  env)  ? 
begin  ~ 

if  IS_ACCESS ( type_dcn)  and  IS_COMPATIBLE ( typc_don , TYPE  DEN (tree  type  den))  then 
declare  “ 

exo2:  constant  TREF  :*  CHEC*K_FX° (exp,  OBJECT_TYPE ( type  den),  env); 
qualified?:  constant  TREE  : *~VAKE  (gun]  i f i ^d  , I"  ( typc_dcn)  , exp2)  ? 

begin 

return  MAKE (ell ocator , qualified?) ? 

end  ? 
else 

return  INCOMPATIBLE  ACCESS  TYPE  DENS; 

end  if; 

end  CHECK— ALLOCATOR  ? 

Dynamic  Seventies: 

procedure  EVAL  ALLOCATOR (allocator:  TREE;  env:  D ENV ; cont:  FVAL  CONT)  return  EXEC  CONT  is 

begin 

--  allocates  dynamic  object,  initializes  it  end  returns  location  of  object 
--  as  access  value 
end  EVAL  ALLOCATOR; 


4.8  Static  Expressions 


A static  expression  is  one  whose  value  does  not  depend  on  any  dynamically  computed  values  of  variables. 
Whenever  the  semantics  require  static  expressions  for  the  definition  of  some  construct,  these  expressions  ere 
evaluated  at  compilation  time  and  they  must  contain  only  the  following: 

(a)  literals 

(b)  aggregates  whose  components  are  static  expressions 

(c)  constants  initialized  by  static  expressions 

(d)  predefined  operators,  functions,  and  attributes 

(e)  qualified  static  expressions 

(f)  indexed  and  selected  components  of  constants 
Static  Semantics: 

procedure  CHECK  STATIC  EXP (exp:  TREE;  type  dor:  R TYPE  DFN;  env:  S ENV)  return  TREE  is 
begin 

— Checks  whether  exp  is  a static  expression  *>n*  returns  a literal 

— corresponding  to  its  value.  If  an  exception  (o.g.,  P:'NGE_EPEr'R 

— or  OVERFLOW)  is  raised  during  this  evaluation,  th'' 
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5.  Statements 


Statements  cause  actions  to  be  performed  when  executed.  A statement  may  be  simple  or  compound.  A simple 
statement  contains  no  other  statement.  A compound  statement  may  contain  simple  statements  and  other  compound 
statements. 


Syntax ; 

sequence^ of_statements  {statement} 

statement 

simplc__statemcnt  I compound_stetrment 
I << idont if icr>>  statement  ” 


simplc_statement 

ass  ignrr<?nt_sta  tement 
I cx i t_stc tement 
I goto  statement 
I initTetc_statemcnt 
I raiso_st~tcment 
j code_statnmcnt 

compound_ste tement 

if_st a tement  I 

I loop_sta tement  I 
I selcct_statemcnt  I 


Guhprogram__call_st  a tement 

rcturn_statcmonT 

asser  t”st a tement 

delay__statcment 

abor  t""sta  temen* 

null 


case_ste  tement 
accept_sta tement 
block 


Abstract  Syntax : 


: : * statement  s 
! : * assign  T call  I 

I i n it  i -»tc  I delay  | 
I i f I case  I 

I label ed 


exit  I return 
r a 1 g e I abort 
loop"  I accept 


I assert 
I null 
I block 


stm  S ->  STM. . . 
labeled  ->  ID  STM 


[STM. . . ] 
{<<in>>  STM] 


Description: 
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A statement  may  bo  labeled,  with  an  identifier  enclosed  by  double  angle  brackets,  e.g.  <<PEPE>>.  Labels  are  - 

used  in  exit  and  goto  statements.  Within  the  sequence  of  st^tem"nts  of  a subprogram  or  module  body,  different 
labels  must  have  different  identifiers. 

U : 


Formal  Definition 


5 


1 
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Execution  of  a null  statement  has  no  other  effect,  blocks  jr"  described  in  th^  next  charter.  Initiate,  dcl?yr 
abort,  accept,  and  select  statements  are  described  In  chapter  9 (Tasks).  Pais"  statements  are  described  in 
chapter  11  (Exceptions).  Code  statements  are  described  in  section  13.3  (Machine  Code  Insertions).  The 
remaining  statements  are  described  here. 

The  statements  in  a sequence  of  statements  are  executed  in  succession  unless  an  exception  is  raised  or  unless 
an  exit,  return,  or  goto  statement  is  executed. 

Static  Semantics ; 

procedure  CHECK_ST!1<stms  TREE;  env:  S ENV)  return  TREE  is 
begin 

case  KIND (stm)  of 


when 

assign 

«> 

return 

CHFCK  ASSIGN 

(stm, 

env)  • 

when 

c-Ol 

*> 

return 

CHECK- CALL 

(stm. 

VOTE , env) ; 

when 

exit 

*> 

return 

CHECK  EXIT 

(stm. 

env)  ; 

when 

return 

*> 

return 

CHECK  RETURN 

(rtm. 

env)  • 

when 

goto 

«> 

return 

CHECK  GOTO 

(stm. 

env)  ; 

when 

^ r t 

«> 

return 

CHECK  ASSERT 

(stm , 

env)  ; 

when 

initiate 

-> 

return 

CHECK- I NITI ATE 

(stm. 

env)  ; 

when 

cV-  1 ->y 

«> 

return 

CHECK- DELAY 

(stm, 

env)  ; 

when 

r : s ■» 

«> 

return 

CHECK  RAISE 

(stm. 

env)  ; 

when 

: Kor  t 

=> 

return 

CHECK  ADOPT 

(stm. 

env)  ; 

when 

ctrS 

»> 

return 

CfTECK_CODE 

(stm. 

env)  ; 

when 

n u I 1 

«> 

return 

stm;  - 

when 

T7 

■> 

return 

CHECK  IF 

(stm, 

env)  ; 

when 

CCS? 

-> 

return 

CHECK  CA.SF 

(stm. 

env)  ; 

when 

1 oop 

»> 

return 

CHECK- LOOP 

(stm. 

env)  t 

when 

recoct 

«> 

return 

CHECK- ACCEPT 

(stm. 

env)  ; 

when 

s~lcrt 

■> 

return 

CHECK  SELECT 

(stm. 

env)  ; 

when 

b i ork 

*> 

return 

CHECK  SLOCK 

(stm. 

env,  EMPTY); 

when 

1 .-bo  Ira 

■ > 

if  I f_LApELED_LOOP ( stm)  then 
declare  — 


cnv2 s constant  3 EW  DECL_MARKFR ( ID (stm) , env); 

begin 

return  HAKE (labeled,  ID(stm),  CHECK  STM (STM (stm) , env2) ; 

end; 

else 

return  MAKE (labeled , I0(stm),  CHECK  STM (STM ( stm) , env)); 
end  if; 
end  case; 

end  C!1SCK_STM» 

procedure  CHECK_STM_S  is  new  CHECK_S (CHECKJ5TM) : 

procedure  TS_LADFLEU_LOOP (stm:  TREE)  return  BOOLEAN  is 
begin 

case  KTND(stm)  of 

when  loop  ■>  return  true; 

when  1 ••'be led  *>  return  IS  LAPFLED_LOOP (STM (stm) ) ; 
when  others  *>  return  faTse;  - 
end  case; 

end  IS  LABELED  LOOP;* 
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procedure  EXEC_STM ( stm; 
begin 

case  KIND (stm)  of 

TPEE ; 

env;  D ENV;  cont; 

: EXEC  CONT) 

r> 

when 

nssien 

*> 

return 

EXEC  ASSIGN (Stm, 

env. 

root)  ; 

when 

c ~ 1 1 

■ > 

return 

EXEC"CALL  (stm, 

env. 

cont) ; 

when 

exit 

»> 

return 

EXSC”EXIT  (Stm, 

env , 

cont)  ; 

o 

when 

return 

»> 

return 

EXEC  RETURN (Stm, 

env , 

cont ) ; 

when 

goto 

«> 

return 

EXEC“COTO  (Stm, 

env. 

cont) ; 

o 

when 

when 

-rr«rt 
nuJ  1 

«> 

■ > 

return 

return 

EXEC~ASSERT(stm, 

contT 

env , 

cont)  ; 

when 

77 

»> 

return 

EXEC  IF  (Stm, 

env , 

cont ) ; 

when 

erne 

»> 

return 

EXEC  CASE  (stm. 

env , 

cont) ; 

o 

when 

loop 

»> 

return 

EXFC  LOO?  (stm, 

env , 

cont ) ; 

when 

when 

block  • 
3 Abell 

*> 

ed  *> 

return 

EXEC  BLOCK  (stm, 

env. 

cont)  ; 

declare 

procedure  CONTINUE (env ; D ENV)  return  EXEC  CONT  is 
begin 

return  EXEC_STM (STM (stm) , env,  cont) 
end; 
begin 

return  DECL_MARKER (id (stm)  , env,  CONTINUE) 
end ; 

end  case; 

end  EXECJ3TM; 

procedure  EXEC  STM  S is  new  EXEC  S(EXEC  STM); 


5.1  Assignment  Statements 

An  assignment  statement  replaces  the  current  value  of  a variable  with  a new  value  specified  by  an  expression. 


assignment  statement 


variable  ;■  expression; 


Abstract  Syntax ; 

assign  ->  NAME  EXP  — I NAME  :■  EXP;  J 
Description; 

The  variable  and  the  expression  must  be  of  the  same  type  and  the  value  of  the  expression  must  be  compitible 
with  any  range,  index,  or  discriminant  constraint  applicable  to  the  variable.  If  the  constraints  *rc  not 
checked  during  compilation,  an  execution  time  check  is  performed  and  raises  an  exception  if  it  fails  (the 
check  may  be  omitted  if  the  corresponding  exception  is  suppressed,  see  31.6). 

Static  Semantics; 
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procedure  CHECK_ASFIGN (essign:  THEE? 
den  t constant  S DF.^  OP  :* 

typc_dcn:  constant  S TYPE  DEV  :* 
name”  : constant  n'!-rE  :• 

exp  : constant  TREE 

begin 

return  MAKE,  { assign , n?n»ef  exp)  ; 
end  CHECK  ASSIGN; 


env:  SJFNV)  return  TPFE  is 
DEN  OF ( N-V'F. ( r.r.sign)  , onv); 

TYPE  DEN (den); 

CFEC^VARIAOLEfNAMP  (assign)  , type_dcn, 
CFECX”EXP (FXP (assign)  , type_den,  env); 


env)  ; 


Dynam  i c Foment  i r s : 


procedure  EXEC  ASSIGN ( assign : TPPE?  env:  DJvNV;  cont:  EXEC  CONT)  return  EXEC  CONT  is 
procedure  CONTTNUSld  val:  v^L)  return  EXEC  CONT  is 
procedure  CONTINUE? ( r_val : VAL)  return  exec  CQnt  is 
-Jen:  constant  D DEN  :»  DE^'  OF  (NAME  (assign) ~,  onv); 
constr_den:  constant  n CO.nftp  DEN  :»  CONSTP_DEN (den) ; 
begin  ~ 

return  TEST  ASSIGN (r_val , constr_den,  UPDATE ( l_val , r_val,  cont)); 
end  CONTINUE 2 

begin 

return  FVAL  EXP  fEXP  (assign)  , env,.  CONTINUE2) ; 
end  CONT T HUE 1; 

begin 

return  LOCATE  (NAME  (assign)  , env,  CONTINUED; 
end  EXEC  ASSIGN; 


5.1.1  Array  and  Slice  Assignments 


For  an  assignment  to  an  array  or  to  an  array  slice  variable,  the  expression  must  denote  a value  with  the  same 
number  of  components.  For  slice  assignments  where  the  slice  value  refers  to  the  same  array  as  the  slice 
variable,  overlapping  of  index  ranges  is  forbidden  and  raises  the  exception  OVEPLAP__ERPCP . 


5.1.2  Record  Assignments 


For  an  assignment  to  a record  variable  declared  with  a specified  discriminant  value,  the  assigned  record  value 
must  have  the  prescribed  discriminant  value.  The  discriminant  of  a record  denoted  by  an  access  variable  cannot 
be  altered,  not  even  by  a complete  record  assignment. 


5.2  Subprogram  Calls 
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A subprogram  call  invokes  execution  of  a subprogram  body.  The  call  specifics 
parameters  with  formal  parameters  of  the  subprogram.  An  actual  parameter  is 
an  expression. 


the  association  of 
cither  a variable  or 


any  actual 
the  value  of 


Syntax : 

subprog  rem_cal 

subprogramme a \ 
suborog7rm 


l_s  tat 
1 

name  [ 


ement  subprog ram_cal 

(parameter_association  { 


1? 


parameter_assoclntion} ) J 


parameter_essociation 

[ form*l_parameter  :■] 

I [ forma l“pa remoter  ■:] 

I f forma l_pa rare ter  :«:) 


actual_parnmcter 
rctu*l~parameter 
act ual”pc remeter 


formal^ parameter  identifier 


nctualjpor ameter  expression 


Pescr i ot i on : 


Actual  parameters  may  be  passed  in  positional 
corresponding  formal  par  err'- tars  (named  p 
corresponds  to  the  formal  parameter  with  the 
the  corresponding  formal  parameter  is  explici 
order . 


order  (positional  parameters)  or  by  explicitly  namirg  the 
ammeters).  For  positional  parameters,  the  actual  parameter 
same  position  in  the  formal  parameter  list.  For  named  parameters, 
tly  given  in  the  call.  warned  parameters  may  be  given  in  any 


Positional  parameters  and  named  parameters  may  be  used  in  the  same  call  provided  that 
occur  first  ot  their  normal  position,  i.e.  once  a named  parameter  is  used,  the  rest  of 
named  parameters. 

Abstract  Syntax : 


cal  1 

-> 

WA'tp; 

?APAM  ASSOC 

P — (WAVS (DA RAM  ASPOC  S) 

c •“ r •' m assoc  s 

-> 

PAR  V 

•'  A eqoC  . . . 

— [PAQ.M  AKSOC,  ...] 

in  ."ssoc 

-> 

T D 

F.V.o 

— Ill)  :»  pypl 

ouf  ---sec 

-> 

TP 

•^yp 

--  r rn  *•  dx°1 

in  out  "nsoc 

-> 

TO 

rvn 

— [T|>.  pyp] 

pADV'  q 

. . 

■ oar 

"SCO c s 

pApv 

: : 

= r/a 

1 in  assoc  1 

out  assoc  ! in  out  assoc 

Norm-" 1 i r - i i or : 

Each  position"1  “s.oo.  { * ion  i « norri  ai  i *<- • into  ■ o-m*  •’  "csoc  i at  ion . 

Static  Semantics: 


positional  parameters 
the  call  must  use  only 
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procedure  CHECK_CALL (cal  l : TREE ; type_dcn:  s type  npN;  env:  S FtfVi  return  TPrr  is 
begin 

return  CHECK  CALL2 (NAME (cal 1 ) , PAR AM  ASSOC  S(call),  type  den,  env) ; 
end  CHECK_CAI.L|” 

procedure  CHCCK_CALL2 (cxt^name:  TREE ; param_assoc_s:  TRET;  typc_den:  S type  DEN;  env:  s ENV)  return  TREE  is 
den_sl:  constant  S DF>1~S  :*  DE'1_0F (oxt_ncme,  env);  — all  denotations  of  the  ext_n*mc 
dcn_s2:  constant  S DFN  S VALTd  OVERLOADIMC_S (den  si,  param  assoc  s,  type^den ,~cnv) ; 

begin  “ 

if  IS  EMPTY (Jen  s?)  then 

return  INCOMPATIBLE  CALL; 
elsif  LENGTH (den  s2)  >“l  then 

return  .AMBIGUOUS  CALL;  s 

else  — solution  oT  overloading  yields  a unique  denotation 

declare 

den:  constant  S DEM  :*  HEAD (den_s2) ; 

id  : constant  TREE  :*  TD(dcn);”  — unique  identifier  associated  with  the  subprogram  declaration 

— which  is  identified  by  the  call 
parom__s  : constant  S DEN  S :■  PARAMOS  (den)  ; 

param“assoc_s2 : constant  TRFE  :*  N0RMA'£ize_PARAM_ASS0C_S  (param_s , param_assoc_s,  env); 

par?m“essoc“r.3:  constant  TREE  :*  CHECKUP  .\RAM_ASSOC_S  (p“rem_s , param_assoc_s2,  env); 

begin  “ 

return  MAKE (cal  1 , id,  param_essoc_s3) ; 

end;  ” . • 

end  if; 

end  CI?ECK_CALL_2; 

procedure  C!!ECK_ PARAM_ASSOC_S (param_s:  DEM  S;  param_ assoc_s : TREE;  env:  S ENV)  return  TREE  is 
begin 

if  I S— EMPTY (parem_s)  then 

return  EMPTY (par  am  assoc  s) ; 

else 

PRE  (CHECK  PARAM  ASSOC  (HEAD(param  s’),  HEAD(param  assoc  s)  , env), 

CHECK“p.ARAM~ASSOC  S (TAIL  (parents)  , TAIL  (param“assoc"s)  , env)); 
end  if;  “ ” ” 

end  CHECK_PARAM_ASSOC_S; 

procedure  CHECK_PARAM_ASSOC (param:  DEN;  param_assoc:  TREE;  env:  S ENV)  return  TREE  is 
begin  — param_assoc  has  been  normalized  to  TlP  :*  EXP] , [ID  ■:  EXP) , or  (I_D  EXP) 

return  MAKE (KIND (param_sssoc) , TD(param  assoc),  CHECK_EXP  (EXP  (p-*rom  assoc)  , TYPE  OPN(perem),  env))); 
end  CHECK  PARAM  ASSOC; 


Dynamic  Semantics: 

procedure  EXEC_CALL(call : TREE;  env:  D ENV;  cont:  EXEC  CONT)  return  EXEC  CONT  Is 
procedure  CONTINUE (p*ram_val_s : PARAM_VAL_S ; ) return  EXEC  CONT  is 
den:  constant  D DEN  :*  DEN_OF (ID (call)7  env); 

begin 

return  den (param  vel  s,  cont) 
end  CONTINUE; 

begin 

return  EVAL_PARAM_ASSOC  S (PARAM  ASSOC  S(call),  env,  CONTINUE); 
end  EXEC  CALL;"”  ” " 
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procedure  rvAi^rAKAv^Assncj? ( poreirj»«isoc_s«  tpfe;  r nv:  n env;  cont:  ^v^L  CQMT)  return  E*rc  cont  is 

begin 

if  IS  EMPTY (narcm  assoc  s)  then 
return  cont (EMPTY)  “ 

else 

declare 

procedure  CONTINUE1  (penn^val : PAPA**  VAL)  return  EXEC  CONT  is 

procedure  CONTINUE  2 (pairam_val_s : PAP  AM  VAL  S)  return  E*EC  CONT  is 
begin 

return  cont (PRE (param  val,  parair^vel  s) ) ; 
end  CONTINUE?; 

begin 

return  EVAL  PARAM  ASSOC  S (TAIL (par am  assoc  s) , e nv,  C0NTINUE2) ; 
end  CONTINUED” 

begin 

return  EVAL_PARAM_ASSOC (HEAD (par am_essoc— s)  , env,  CONTINUED; 
end; 
end  if; 

end  EVAL_PARAM__ASSOC_S; 

procedure  EVAL_PAPAM_ASSOC (param_assoc:  TREE;  env:  D ENV;  cont:  EVAL  CONT)  i , jrn  EXEC  CONT  is 
procedure  CONTINUE (val : VAL)  return  EXEC  CONT  is 
begin 

return  cont  (PARAM__VAL  ( ID  (param_assoc) , NATURE (param  assoc),  val)); 
end  CONTINUE; 
begin 

case  KlND(p?ram__assoc)  of 
when  in  rr-soc  ■> 

return  EVAL_EX?  (EX*>  (parem_assoc)  , env,  CONTINUE); 
when  out  assoc” ( in  out  assoc  *> 

return  LOCATE (EXP (par*m_assoc) , env,  CONTINUE); 

end  case; 

end  EVAL  PARAM  ASSOC; 


5.2.1  Actual  Parameter  Associations 

There  are  three  forms  for  specifying  actual  parameters 

(a)  Input  parameter  association 

( formal_parameter  :*]  actual_parameter 

The  corresponding  formal  parameter  must  have  the  mode  in.  Its  value  is  provided  by  the  actual  parameter, 
•to 

(b)  Output  parameter  association 

9 

( formal^parameter  »:]  actual^ parameter 

The  corresponding  formal  parameter  must  have  the  mode  out.  Tts  value  is  assigned  to  the  actual  parameter 
as  a result  of  the  execution  of  the  subprogram. 
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(c)  Inout-outcut  parameter  association 


[formal  parameter  :■:)  actual  parameter 

1“ 

The  corresponding  formal  parameter  must  have  the  mode  in  out.  Within  the  subprogram,  the  formal  parameter 
permits  access  and  assignment  to  the  corresponding  actual  parameter. 


An  expression  used  as  an  in  parameter  is  evaluated  before  the  call.  An  expression  used  as 
actual  parameter  must  be  a variable  or  a qualified  variable.  The  identity  of  a variable 
parameter  which  is  a selected  component  or  an  indexed  component  is  established  before  the 


an  out  or  in  out 
out  or  in  out  actual 

call  . 


5.2.2  Omission  of  Actual  Parameters 

An  in  parameter  may  be  omitted  from  the  actual  parameters  if  the  subprogram  declaration  specifies  a default 
value  for  the  corresponding  formal  parameter.  In  such  cases,  any  remaining  actual  parameters  must  be  named. 

5.2.3  Restrictions  on  Subprogram  Calls 


The  type  and  constraint  of  each  actual  parameter  must  be  consistent  with  those  of  the  corresponding  formal 
parameter,  as  for  assignment.  To  prevent  aliasing  (i.o.  multiple  access  to  the  same  variable),  a variable 
which  is  used  a3  an  actual  out  or  in  out  parameter  may  not  be  used  as  another  parameter  of  the  same  call.  For 
this  rule,  any  variable  that  is  not  local  to  the  subprogram  body  is  considered  as  an  implicit  in  parameter  if 
its  value  is  read,  and  is  considered  as  an  in  out  parameter  If  it  is  directly  or  indirectly  updated  as  a 
result  of  the  call. 


5.3  Return  Statements 

A return  statement  terminates  execution  of  a subprogram. 

Syntax : 

return^statement  return  [expression]: 

Abstract  Syntax : 

return  ->  EXP  void  — [ return  EXP  VOID:  ] 

Dcscr jet  ion: 

A return  statement  car  only  appear  in  s^euenen  of  statements  of  a subprogram.  A return  statement  must  not 

appear  ir  nn  accept  star e went . eor  ^unctions  or  v-hi?  returning  procedures,  a return  statement  must  include 
an  expression  whose  value  is  the  result  of  the  subprogram. 

Static  Shanties: 
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procedure  CHECK  RETURN  (return:  TREE?  env:  5 CMV)  return  TREE  is 

type_dcn:  constant  S TYPE  DEN  :■  RESULT  (CUKRENTJ5UPPROGRAM (env) ) : 

begin  " 

if  not  IS  IN’  SUBPROGRAM  (env)  then 

return"RETURN  ONLY  ALLOWED  IN  SUBPROGRAM  nODY; 
elsif  IS  IK  ACCENT  (env)  then" 

return  RETUR'.J_NOT_ALLO"ED  IN  ACCEPT  STATEMENT; 
elsif  TS_INVALin  RETURN ( FXP  VOID (return) , type  don)  then 

return  FETUR;OnC0MPATTBLE_WITH_SURPR0GPAM_PESULT; 

else 

case  KIND (EXP_VQTn (return) ) of 
when  void  " *>  return  return; 

when  otHers  *>  return  MAKE (return,  CHECK_EXP (EXP_VOTO(return) , type_den,  env)); 
end  case; 
end  if; 

end  CHECK— RETURN ; 


procedure  IS_INVALID__FETURN (exp_void : TREE;  type_den:  S_TYPE_DEN;)  return  POOLEAN  is 
begin 

case  KIND (oxp_void)  of 

when  void  " ■>  return  type_den  /■  VOID; 
when  others  *>  return  typc"den  * VOTD; 
end  case; 

end  TS_VALID  RETURN; 
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Oynan 1c  ont les: 

procedure  EXEC_RETURN(ret.urn:  TREE;  env:  P ENV;  cont:  EXEC  CONT)  return  EXEC  CONT  1b 

begin 

case  KIND (EKR  VOID(stn))  of 

when  void  " ->  RETURN  EXEC  CONT(env)); 

— RtifURN  EXEC  CONffonvT  Is  the  continuation  of  the  current  procedure  call 
when  others  •>  EVXi,_EXP  (EXP_VOID  (stm)  , env,  RETUPN_EVM,_CONT (env) ) ; 

— RETURN_EVM,_CONT(envl_is  the  continuation  of“the  current 
— function  or-value  returning  procedure  call 
end  case; 

end  EXEC  RETURN  STM ; 


O 

O 


° I 


i 


o 


5.4  If  Statements 


An  if  statement  effects  the  choice  of  a sequence  of  statements  based  on  the  truth  value  of  one  or  more 
conditions.  The  expressions  appearing  in  conditions  must  be  of  the  predefined  type  POOLEAN. 

Syntax : 

if_statement 
” if  condition  then 
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sequence  o restatements 
(elsif  condition  then 

sequence  of  statements) 

(else 

sequence_of_statements) 


o 

end  if?  ” “ 

o 

condition 

expression  {and  then  expression) 

1 expression  {or  else  expression) 

Ca 

o 

Abstract  Syntax: 

O 

o 

o 

if  ->  CONDITIONAL  S STtf  LIS  — fif  CONDITIONAL  S else  STM  S 

end  If;) 

rs 

cond  i t ionel  s ->  C0KDITI0"M.. . . — ( conditional  elsif  ...  T 

cor-Ht(or.?l  ->  COMO  STM  5 — [C^ND  then  STM  51 

condition  ->  FXP  CONDITION  OP  C OVD  — I F V p CC!MDTTTON  OF  COND] 

nn:l  then  ->  exp  CO'’0TTT"M  OP  fOMD  — [5n3  thenl 

or  else  ->  FXP  CO»DTTTOM  OP  TON'D  — (or  else] 

U 

o 

o 

o 

CONDITIONAL  S cond i t ionnl  s 

CONDITIONAL  ::*  con^i t ion ” 1 

CCND  FXP  1 condition 

CONDITION  OP  7171  then  I or  else 

o 

o 

o 

Description: 

o 

o 

o 

o 

Execution  of  an  if  statement  results  in  evaluation  of  the  conditions,  one  after  the  other  (treating  a final 
else  as  elsif  TPUE  then),  until  one  evaluates  to  TRUE?  then  the  corresponding  sequence  of  statements  is 
executed.  If  none  of  the  conditions  evaluates  to  TPUE,  none  of  the  sequences  of  statements  is  executed. 

o 

o 

Normalization: 

o 

o 

I if  CONDITIONAL  S else  STM  S end  if:l  -> 

(if  CONDITIONAL  S elsif  true  then  STM  S end  1 f ; 1 

o 

o 

Static  Semantics: 

c c 

procedure  CdECK  TF(if:  TREE:  env:  S ENV)  return  TPE*  Is 

CPv2 : 5 PMV  :•  LA?ELS_IN (CONDITIOMAL_S ( i f ) , env): 

begin 

return  MAKE  (_i_f  , CHECK_COND!TIONAL_S  (CONDITTONMJ!  ( i f ) , env2)  , EMPTY): 

end  CUECK_IF? 

procedure  C!!ECK_CONDITIONALJ?  is  new  CHECKJ5  (OIECK_CONDITIONAL)  ? 

procedure  CHECK_CONDITIONAL (condi tional : TREE;  envi  s CNV)  return  TREE  is 
begin 
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return  MAKF(condttionM , CHECK  COND (COND (cond i tional ) , cnv) , CHECK  STM  S (STM_S (conditional ) , env) ) ; 
end  CHECK  comdittTvTmTJ 


Dynamic  Semantics: 

procedure  EXEC  CONDITIONAL (cond it  Iona 1 : TPFE;  cnv:  DEW?  cont:  FXEC  CONT)  return  FXEC  CONT  is 
procedure  CONTINUE (val : VAL)  return  EXeT" PONT  is 

begin 

if  noOLEAV(val)  then 

return  EXEC_STM_S (STM_S (conditional ) , env,  cont); 

else 

return  cont; 
end  if; 
end  CONTINUE ; 

begin 

return  FVAL  CONO (COND (cond i tional ) , env,  CONTINUE); 
end  CXF.C  CONDITIONAL; 


5.4.1  Short  Circuit  Conditions 


A condition  may  appear  as  a sequence  of  boolean  expressions  separated  by  and  then.  In  such  a case,  evaluation 
of  the  constituent  expressions  proceeds  in  textual  order  until  one  evaluates  to  FALSE , in  which  case  the  value 
of  the  condition  is  FALSE;  the  condition  is  true  only  if  all  expressions  evaluate  to  TPUE.  Similarly,  for 
expressions  separated  by  or  else,  evaluation  stops  as  soon  as  an  expression  evaluates  to  TRUF.,  in  which  case 
the  value  of  the  condition  is  TPUE;  the  condition  is  false  only  if  all  expressions  evaluate  to  FALSF . 


Static  Semantics : 

procedure  CHECK_COND (cond:  TREE;  env;  S ENV)  return  TREE  is 
begin  ” 

if  IS_EXP (cond)  then  — f EXP  ) 

return  CHECK  EXp(cond,  BOOLEAN  TYPE,  env); 
else  --  IMP  CSnCTTTON  OP  CON'D  ]~ 
declare 

exp  : TPEE  CHECK_EXP (EXP (cond) , BOOLEAN  TYPE,  env)  ! 
cond2 : TPCE  CHECK_CONO (COND (cond) , env) 

begin 

return  WAKE (condition , exp,  CONDITION_OP (cond) , cond2)j 

end! 
end  if; 

end  CHECK  COND) 


Dynamic  Semantics 
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procedure  EVAL  COND (cond:  TI»FE»  env:  t>  RNV;  cont:  EVAl,  CONT)  return  FXFC  CONT  1* 

begin 

if  IS_EXP(cond)  then  — |ex°1 

return  EVAL_EXP (cond , env,  cont); 
else  “ — tEXP  CONDITION  OP  COND  | 

return  EVAL  CONDITION (cond , env,  cont); 

end  if;  “ - ' 

end  EV.AL  COND; 

o / 


procedure  EVAL_CONDTTION (condi t ion:  TREE;  env:  D ENV ; cont:  EV»L  CONT)  return  EXEC  CONT  is 
procedure  C5NTINUE1 (val : VAL)  return  EXEC  COMT  is 
begin 

if  BOOLEAN (val)  then 

return  EVAL_COND (COND (condi t ion) , env,  cont); 
else 

return  cont (val) ; 
end  if; 

end  CONTTNUEl ; 

procedure  C0NTINUE2 (val : VAL)  return  EXEC  CONT  is 
begin 

if  POOLEAN ( val ) then 
return  cont (val ) ; 
else 

return  EVAL  COND (COND (condition) , env,  cont); 
end  if; 

end  C0NTINUE2 ; 

begin 

. case  CONDITION  OP (cond i t ion)  of 

when  and  then  »>  return  EVAL_EXP  (EXP  (exp)  , env,  CONTINUED; 
when  or  else"  *>  return  EVAL_EXP (EXP (exp) , env,  C0NTINUE2) ; 
end  case;  ” 

end  EVAL  CONDITION; 


5.5  Case  Statements 


A case  statement  selects  and  executes  one  of  several  alternative  seouences  of  statements.  The  selection  is 
based  on  the  value  of  an  expression,  of  a discrete  type,  given  at  the  head  of  the  case  statement. 

Syntax:  / 

cese_ statement 

case  expression  of 

(when  choice  (I  choice)  ■>  sequence^ of_statements } 

end  case; 

Abstract  Syntax: 
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C3C0 

^ I r ? r n * t i v e s 
~ ! t •:  r r c t i v o 

ALTERNATIVE  S 
ALTi."  ??,,AT  T VE 


->  F*P  ALTERNATIVE  S 
->  alternative  ... 

->  CMOTCE  S STVI  s 

: : ■ alternative  s 
: : = >-•  1 t e r p ■->  t i v e 


f case  F*R  of  ALTERNATIVE  s end  case;  1 
1 ALTFFNA  f T VE  ...  1 
[ when  CMOTCE  S =>  ftm  S ] 


Poser int ion : 


Each  alternative 
Choices  given  in 
aggregates  (see 
one  and  only  one 
all  values  not 
limit  the  number 


is  preceded  by  a list  of  choices  specifying  the  values  for  which  the  alternative  is  executed, 
case  statements  follow  the  same  rules  as  choices  given  in  component  associations  for  array 
3.6.2).  Thus,  each  possible  value  of  the  typo  or  subtype  of  thn  expression  must  be  given  for 
alternative;  the  choice  others  can  be  given  as  the  choice  for  the  last  alternative  to  cover 
given  in  previous  choices.  Not**  that  it-  is  always  possible  to  use  a qualified  expression  to 
of  choices  that  need  be  given  explicitly. 


Static  Semantics: 


procedure  CHECK_CASE (case : TREE;  env:  S ENV)  return  TREE  is 

env2  : constant  S ENV  :»  LARELS_IN  (ALTERNATIVES  (case)  , env); 

tyce_dcn  : constant  S TYPE  DEW  : =»  TYPE_OF  ( EXP  (case)  , env2)  ; 

exp  : constant  TREE  :*  CHECK  EXP  (EXP  (case) , tyoe_den,  env2) ; 

alternative's:  constant  ALTERATIVE  S :»  CHFCK~ALTERNATIVE_S (ALTPRNATTVE_S (case) , type  don,  env2) ; 

begin 

if  not  IS  DISCRETE (tyoe  den)  then 
r e t u r n~T  Y P E_M  U 3 T J3  F._D  T SC  R F.T  E ; 
elsif  not  IS  EXHAUSTIVE (alternative  s,  type  den)  then 
return  CHOTCE_S_MUST_RE_EXHAUSTIVE ; 

else 

return  MAKE (case,  exp,  alternative  s) ; 
end  if; 

end  CHECK  CASE; 


procedure  CHECK_ALTERNATIVE_S  is  new  CHECK  S2(S  TYPE  DEN,  CT!ECK_ALTFRNATTVE) ; 

procedure  CHECK  ALTERNATIVE (alternative:  TREE;  type  den:  S TYPE  DEN;  env:  S ENV)  return  TREE  is 
choicc_sl:  constant  TREE  : = CHECK_cnOICE_S (CHOTCf_S (alternative) , type_.3rn,  env); 
choice_s2:  constant  TREE  :*  N0PMALI7!E_CH0TCE_S  (choice_sl , type_dcn)  ; “ 

— normalizes  each  choice  such  that  a Tange  is 

— replaced  by  a list  of  choice  values 

stm_s:  constant  TREE  CHECK  STM_S (STM  S (al ternet i ve) , env); 

begin  “ 

return  MAKE  («-]  ternative,  choice_s2,  stm  s)  ; 
end  C!!ECK_ALTERNATI VE ; 
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Dynamic  ics t 

procedure  TXFC  CASE(case:  TREE;  env:  D FNV;  cont;  PXEC  CONT)  return  EXEC  CONT  is 
cnv2s  constant  D F?»?y  :»  LABELS  IN  ( ALTERNATIVE^?  (case)  , cnv)  ; 
procedure  CONTINUE (val : VAL)  return  EXEC_CONT  is 
begin 

return  FXEC  ALTERNATIVE  S (ALTERNATIVE  S(case),  val,  cnv2,  cont); 
end  CONTINUE;  ” ” . 

begin 

return  FVAL  EXP (EXP (case)  , env2,  CONTINUE ) ; 

end  EXEC  CASE;  0 j 


procedure  EXEC_ALTERNATIVE_S  is  new  EXEC  S?(VAL,  EXEC_ALTEPNATTVE_S) ; 


procedure  EXFC_AL7EPNATrVE (alternative;  TREE;  val:  VAL;  env:  P_ENV:  cont:  EXEC  CONT)  return  FXEC  CONT  is 
choice_S:  constant  TREE  :*  CHOTCE_S (aTterna t ivc) ; 
sta_ s “ ; constant  TREE  :=  STM_S (alternative) ; 

begin 

if  IS_EM?TY(choicc_s)  then 
return  cont;  ~ 
else 

declare 

a 1 ternat ive2 : constant  TREE  :*  MAKE (al tcrn»H ve , TAIL(choice  s) , stm  s)  ; 

procedure  CONTINUE  (val 2:  VAL)  return  FX^C  co^T  is 

begin 

if  val  = val2  or  val2  * others_val  then 

return  EXEC_ STM_S (STM_S (alternative) , env,  cont); 
el  se 

return  EXEC  ALTERNATIVE (al ternat ive2 , env,-  cont); 
end  if; 
end ; 
begin 

return  EV.AL_EXP  (HEAD  (choi  ce_s)  , env,  CONTINUE); 
end ; 
end_if ; 

end  EXEC_ALTEPNATIVE; 


5.6  Loop  Statements 


A loop  statement  specifies  that  a sequence  of  statements  in  a basic  loop  is  to  be  executed  repeatedly  zero  or 
more  times.  Execution  is  terminated  either  when  the  iteration  specification  of  the  loop  is  exhausted  or  when 
an  exit  statement  within  the  basic  loop  is  executed. 


Syntax; 

loop_statement  f i teration_srecif ication]  tesic_Joop 
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_C_ 
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basic_loop 

loop 

scauencc_o f_sta  temonts 
end  loop  [identifier]; 

iteration  specification 

for  Toop_parameter  in  [reverse]  discrote_rangc 
I while  condition 

loop__par  ameter  identifier 

Abstract  Syntax? 


1 oop  ->  ITERATION  STM  S 

for ~ ->  22  RANGE 

rr  10 rre  ->  22  RANGE 

vhTTe  ->  EYD 


— [ ITERATION  loop  STM  S end  loop;  ] 

— [ (or  ID  in  P»»;qe~1 

— [ for  22  in  reverse  RANGE  1 
--  [ while  F/2  1 


for  I reverse  I while  I void 


Dcscr i ot ion : 

In  2 loop  statement  with  a while  clause,  the  condition  is  evaluated  and  tested  before  each  execution  of  the 
basic  loop.  If  the  while  condition  is  TRUE  the  loop  is  executed,  if  FALSE  the  loop  statement  is  terminated. 

In  3 loop  statement  with  a for  clause,  the  discrete  range  is  evaluated  only  once,  before  execution  of  the  loop 
statement.  The  loop  parameter  is  implicitly  declared  as  a local  variable  whose  type  is  that  of  the  elements  in 
the  discrete  range.  On  successive  loop  iterations,  the  loop  parameter  is  successively  assigned  values  from  the 
specified  range.  The  values  are  assigned  in  increasing  order  unless  the  reserved  word  reverse  is  present,  in 
which  case  the  values  are  assiqned  in  decreasing  order. 

If  the  range  of  a for  loop  is  empty,  the  basic  loop  is  not  executed.  Within  the  basic  loop,  the  loop  parameter 
acts  as  a constant.  Hence  the  loop  parameter  may  not  be  changed  by  an  assignment  statement,  nor  may  it  be 
given  as  an  out  or  in  out  parameter  of  a subprogram  call. 

If  a loop  is  a labeled  statement,  the  label  identifier  must  be  repeated  at  the  end  of  the  loop  after  the 
reserved  words  end  loop. 

Static  Semantics; 

procedure  CHECK_LOOP (loop:  TREE;  env:  S ENV)  return  TREE  is 
env2 : constant  S ENV  :»  IN_LOOP (env) ; 

env3:  constant  S cvy  :■  LAPSLS— IN  STM_S(STM  S(loop),  env2) ; 

iteration_cnv  : constant  TREE  ENV  : = CHECK^TTERATTCN ( ITERATION (loop) , env); 

stm_s  “ : constant  7 REE  :=  CHECK~STM_S (STM_S ( loop) , ENV ( i ter  at i on_env) ) ; 

begin 

return  MAKE (loop,  TREE ( i terat ion_cnv) , stm_s) ; 
end  CF»ECK_LOOP; 

procedure  CHECK_ITER'TIO,l ( i terat ion : TREE;  env:  S em7)  return  TREE  ENV  is 

begin 

case  KIND ( i teration)  of 

when  for  — [ for  TP  in  RANGE  ] 
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I 


n 

O 

O 


I r^v-r^  *> 
declare 

tyt?c_rTrr  r 
r-~pg“  : 

d^sdcn  : 
iC^nv  : 
env?  : 

i tor ->t  ion 2: 

begin 

return  7FEr  • 


[ for  22  in  reverse  r-v^R  ] 


constant  r Type  ppm 
constant  THE- 
constant  c QFSQFN 
constant  TREE  ic^v 
constant  r rvy 
constant  T P e 


rvvr^OF  (P'V'"’  (itrr  on)  , env) ; 

C"F C77  RAMcr  (RAVOF  ( i trret  ion)  , type  den,  env)  ; 
epsCP.TPTIOM  (tyr>c_dcn,  EMPTY)  ; 
nrCL(ID( iteration)  , con r. tent , dosden,  FMPTY) ; 
MreTrnjMV(r>nv,  E^V(id_crv)  ) ; 

MAKE  (kTno  ( i teret  i on)  , TD(id_cnv),  range); 


r.'V(  i ter.?t  ion2,  env?); 


end ; 


when  while  *>  — ( while  EXP  1 

declare 

exp  : constant  TREE  : = CHECX_EX? ( EXP ( i ter at  ion)  , POOLFAN_TYPE , env); 

itcr?Mon2:  constant  TI-ES  VM<£  (while,  exp); 

begin 

return  TPET^E'-’Vf  i teretion2,  env); 
end ; 

when  voi^  => 

return  TREE  EHV(void,  env); 

end  case; 

end  CHFCK^lTFIsATTONI ; 


n 

c 

o 

o 

i 

O ! 
O 


O 

o 

o 

sJ 


procedure  EXFC_LOOP ( loon:  Tpe^;  env;  r>  gvy?  cont:  FXEC  CQMT)  return  EXEC  CO’1  T is 
cnv2 ; constant  D FMV  :*  set  LOOP (env,  cont); 

cnv3 : constant  P EUV  : = LAEELS_!N_STM_S  (STM_S  ( loop)  , cnv2,  cont); 
begin 

case  KIND  ( ITERATTO*1  ( 1 oor)  ) of 

when  Tor  =>  --  ( for  22  1°  E loop  STV  g end  loop;  ] 

return  EXEC_FOR_LOOP ( loop,  -tv?,  cont); 
when  r?v:r?o  =”  --  [ for  to  in  reverse  P.XVGE  loop  STM  c end  loop;  ) 

return  EXeC_REVSFSF_LCOF ( 1 oep , env3,  cont); 
when  wh  i 1 ■-  *“  --  f while  RX?  loop  ST’i  s end  loop;  ) 

return  rXFC_  MTf.E  LOO?  ( 1 on.;  , -nv?,  cont); 
when  v n i •*  *T  --  T loop  FT"  s end  loop;  j 

return  EXEC_ST,,_"  (st  ( 1 oop)  , erv,  EXRC_LOOP  ( 1 oop,  env,  cont)); 
end  case; 
end  R/rr  LOOP; 


procedure  EXEC_FOR^LO^o  ( 1 nop:  TFr‘?;  ^nv;  R E»JV;  cont;  FXEC  CQET)  return  EXEC  COVT  is 
iteration:  constant  'tRE*7'  ;*  T7rs*TTe-T  ( ] on*:)  ; 

tv — : constant  r TYPE  • = :v""  o?  ("vtr  (pavos  ( i tor  at  ion) ) , env); 

procedure  c: :tt  mif]  ( •,  ■ 1 r , 211'  return  rvre  CENT  is 

procedure  CO,-TT\,i»r*2  (v  - 1 • v'M  return  rvre  Ca"T  is 

procedure  C~-  rr*'f,r  u.  r • ? : r -vi  return  '"'.re  cr",’r  is 

begin 

return  FXEC  rTM  F (ST  ^ ( 1 oop ) , env?,  CCYTT>WE2  (StJCC  (val , type  den))); 

end  CS*’TT-$?tf7;  ~ “ 
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begin 

if  L?(vol#  vol2,  typ«»_den)  then 

return  DECL ( JD { i tor »t ion) , constant , val,  "nv,  CONTINUE 3) ; 

else 

return  cont; 
end  if; 

end  CCfJTinUE2; 

begin 

return  CONTINUE? (veil) » 
end  CONTI NU El; 

begin 

return  FVAL  P.ANGE  (RANGE  ( iteret  ion)  , env,  CONTINUE))  ; 
end  EXEC  FOR  l30P; 


procedure  nXEC_rFVEPSE_LOOP  ( loop;  TPFF;  onv:  n ENV-  cont:  rXFC  CONT)  return  FXCC  CONT  is 
iteration:  constant~TRFE  :»  TTFFATTON (loon) • 

type  dm  : constant  P TYPE  PPM  :«  TYPF  OF  (VAV*7  (PV’RE  (iteration))  , env)  ; 
procedure  CONTINUE!  (vclT,  'vel>:  VAL)  return  ryre  covt  is 
procedure  CONTINUE 2 ( val : VAL)  return  FXrc  Ccwt  is 

procedure  CONTTMUE3 (cnvTT  D ENV)  return  rv-T  CONT  is 
beg  in 

return  EXEC  STM  S (STM  S ( loop). , cnv2,  CONTINUE  2 (PBFD ( val , type  den))); 
end  COUTINUS3;~ 

begin 

if  LF ( va 1 2 , val,  typc_don)  then 

return  DECL(IP(ito7etion) , constant , vel,  env,  CONTINUE 3) ; 

else 

return  cont; 
end  if; 

end  CONTINUE2; 

begin 

return  CONTINUE2  (val2) ; 
end  CONTINUE If 

begin 

return  EV\L  RANGE (RANGE ( iteret ion) , env,  CONTI NUEl) ; 
end  EXEC_FEVERSE_LOOP; 


procedure  FXEC_WHTLE_LOOP ( loop:  TPEE;  env:  P ENV;  cont:  F.XFC  CQWT)  return  FXF.C  CONT  is 

procedure  CONTINUE (val : VAL)  return  EXEC  COMT  is 
begin 

if  BOOLEAN (vel ) then 

return  EXEC_STM_S (STM_S ( loop) , env,  EXEC _WHTLE_LOOP ( loop,  env,  cont); 
else  - - - - - 

return  cont; 
end  if; 
end  CONTINUE; 

begin 

return  EVAL  EXP (EXP (loop) , env,  CONTINUE); 
end  EXEC_WHILE"LOOP; 
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An  cxit  statement  causes  explicit  termination  of  an  *'nc1o3ina  loon. 
Syntax : 


exit_statenicnt  exit  ( ident i f i 1 
■>bst  r -ct  Syntax  : 

cxit  ->  TP  VO TP  COMP  VOTP  — 

COMP  VOIP  : : ■ CO^P  I void 


(when  condi t ionl ; 


( exit  TP  VOTP  when  COM3: 
f exit  tr  v^fp;  » 


1 


Pcrcc iot ion: 

The  loop  exited  is  the  innermost  loop,  unless  ►he  '’xit  statement  identifies  label  of  rn  enclosing  loop,  in 

which  case  the  named  loop  is  exited.  The  cxit  statement  may  contain  a condition,  in  which  ccr.c  termination 
occurs  only  if  its  value  is  TRUE.  An  exit  statement  may  only  appear  within  a loop.  An  exit  statement  cannot 
transfer  control  out  of  a subprogram,  module,  accept  statement , or  execution  handler. 

VorTa 1 i 2 3 t i on : 

(exit  TP  VOTP  when  COUP? 1 -> 

( if  C0:’0  “then  exit  TD  VOID  end  if;  1 

Static  Semantic0! 

procedure  CHEC^\_EXIT(exit:  TREE;  env:  S ENV)  return  TFpE  is 
begin 

if  IS  JM_LOOP  (env)  then 

case  KTvp(7P_V0TP(cxit) ) of 
when  void  »>  — ( exit;  ) 
return  exit; 

when  i£_  =>  — f exit  IP;  ) 

if  7S_*ARKEP(I0_V0TP(oxit) , env)  then 
return  exit; 
else 

return  EXIT  IPENTIFIER  MUST  BE  VIST°I.F  LOOP  LA*FL; 
end  if; 
end  case; 
else 

return  FXIT_ONLY_FROM_WITnTN_LOOPS ; 
end  if; 

end  Cl!ECK_EXIT; 

Pynam i c Sment  ics: 

procedure  EXEC_EXIT(exit ; TREE;  env:  P EMV;  cont:  EXEC  C^T)  return  EXEC  CO*T  is 
begin 

case  KIND (IP_VOID(cxit) ) of 
when  void  *>  — ( exit;  1 

return  LOOP_CONT (env) ; — the  continuation  of  the  current  loop 
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when  _ld  •>  — I exit  in;  ) 

return  NAPKER_VAL(IP_V0l0(exit) , cnvli 
end  case: 
end  EXEC_EXIT; 


r> 

o 

o 

o 

o 


5.8  Goto  Statements 


The  execution  of  a goto  statement  results  in  an  explicit  transfer  of  control  to  mother  statement. 

Syntax: 

goto_statemcnt  goto  identifier: 

Abstract  Syntax : 

goto  ->  i_o  — ( goto  i£:  l 
Descrietion: 

The  statement  to  which  control  is  transferred  must  be  labeled  with  the  Same  identifier.  The  designated 
statement  end  the  goto  statement  trust  both  fc>e  within  the  same  subprogram,  module,  or  accept  statement. 

A goto  statement  cannot  transfer  control  from  outside  into  a compound  statement,  block,  subprogram,  module, 
accept  statement,  or  exception  handler.  Tt  may  transfer  control  from  one  of  the  seouences  of  statements  of  an 
if  statement  or  a case  statement  to  another. 
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A goto  statement  canndt  transfer  control  out  of  a subprogram,  module,  accept  statement,  or  exception  handler. 
Static  Semantics: 

procedure  CHECK  GOTO(goto:  TREE;  env:  D ENV)  return  TREF  is 
begin  — 

if  IS  LV5EL(ID(goto)  , env)  then 
return  goto; 
else 

return  IDENTIFIER  IN  GOTO  MUST  BE  VISIBLE  LABEL; 
end  if; 

end  CIIECK_GOTO; 

Dynamic  Scm.ant  ics: 

procedure  EXEC_GOTO (goto:  TREE;  env:  D ENV,  cont:  FXEC  CO«T)  return  EXEC  CONT  is 
begin  “ 

return  LABEL  CONT(IDigoto) , env); 

end  EXEC  GOTO; 
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5.9  Assert  Statement 
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An  assert:  statement  states  that  a condition  must  hold  whenever  control  reaches  th«t  point  in  th<»  proir»m. 
Syntax  t 
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asser t_statement  assert  condition* 

Abstract  Syntax: 

assort  ->  COND  — ( assort  COND;  ) 

Poser int ion : 

The  execution  of  an  assert  statement  causes  the  evaluation  of  the  condition,  ar  reaction  ASSCTT  rnpop  is 

raised  if  the  condition  is  false.  ” 

Execution  of  assert  statements  may  be  omitted  when  the  exceotion  assert  ERPOR  is  sunot  “-y  a pranma  (see 

11.6). 

Static  2l2£ntl£S; 

procedure  CHECK_ASSDRT (assert:  TREE:  env:  S ENV)  return  TREE  is 
begin 

return  HAKE  (assert,  CHECK  COND(COWD(assert)  , POOLE  A''_TYPE , env): 
end  CHECK_ASSEPT; 

Dynamic  semantics: 

procedure  EXEC_AESERT (assort:  TRFE;  cnv:P  ENV:  cont:  EXEC  CQ'IT)  return  EXEC  CQ"T  is 
procedure  CONTINUE (val : VAL)  return  EXEC  CO'T  is 
begin 

if  nocLr’AN(vel)  then 
return  cont; 
else 

return  FXEC  PAISE(assert  error,  env) 
end  if; 
end  CONTINUE: 
begin 

return  EVAL  COND (COND (assert) , env,  CONTINUE): 
end  EXEC  ASSERT; 
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5.10  Auxiliary  Definitions  for  Labels 


Normalisation: 

The  following  functions  are  used  to  ensure  that  labels  are  not  multiply  defined  within  subprograms  or  modules. 

procedure  LAPELS_IN_STK(stm:  TREE;  lobc)_6:  TREE)  return  TREE 
begin 

esse  kind (stm)  of 

when  labeled  »>  — I <<  ID  >>  STMl 
If  IS  IN ( ID  (stm) , labcT  s)  tKen 


Form.'  1 r>!  r ini  Mon 


Pr^-*  lir.fp**ry  or  “ft 
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return  ERROR_LAPELE_must_PE_umtouE; 

else 

return  LARELS_IN_STM(STM(stm) , PPEfTO(Btm)  , l'bel_s)); 
end  1C; 

when  if  ->  — 1 If  COHDITONAL  S end  If;  ) 

return  LAPELS  IS (COWDITTb'JM.  5(st'm),  label  s)  ; 
when  c-sc  *>  (case  EXP  o7  ».LrE»y»TTVF  s end  case;  1 
return  LASELS_IH  (ALTCRNA'riVE_S  (stm)  , ) -bol_s) ; 
when  1 i";  — — [ TTrnflTTOS  loop  STS  s end  loop:  ] 

recent  •>  — ( accept  name  (OBCL  S)  do  ST'<  s end:  ) 
return  LAPELS  IN  STS  S(STM  S(str),  lahel  s) ; 
when  n'l<-ct  «>  --  T select  alternative  S else  ST'-  s end  If:  ) 

return  LAPELS  IN  STM  S (STM  S(stn>) , CS?ELS  is ( alternative  S(stm),  label  s) ) ; 
when  block  «>  --  (declare  DECL  part  begin  ST"  s exception  ALTERNATIVE  S end; 

return  LAPELS_IN  ( ALTERNATE VE_S  (stm)  , LACELS_IM_STV_S  (ST;'_S  (stm) , 1 rbel_s) ) ; 
when  others  •>  — 
return  label_s; 
end  case; 

end  L".PELS_TN_STM; 


procedure  LAPELS_IN_STM_S  (stm_s : TREE;  label_s:  TREE)  return  TPEE  Is 
begin 

If  IS_EMPTY(stm_s)  then 
return  label“s; 
else 

return  LAPELS  IN_STM_S (TAIL (stm_s) , LAPELS_I);_STM(HEAP(stm_s)  , labcl_s>>; 
end  If; 

end  LAPELS_IN_STM_S; 

procedure  r.A'”JLs_lN ( 1 i st : TPFF;  labol_s:  TREE)  return  TEfc  Is 
begin  — list  is  cond  i t ional  s or  alternative  s 
If  IS  empty (list)  then 
return  label_s; 
else 

return  LAPELS  IN (TAIL(1 1st) , LABELS  IN_STM  S (STM  S (HEAD ( 1 i st ) ) , label  s) ) ; 
end  if; 

end  LAPELS  IN; 


Static  Semantics ; 

The  following  functions  are  used  to  declare  labels  loc-1  to  a compound  statement,  block,  subprogram, 
accent  statement  or  exception  handler  to  ensure  th"  proper  visibility  of  labels  (see  5.6,  5.7). 

procedure  LAPELS_IN_STM(stm_s:  TREE;  env:  S EMV)  return  s ENV  Is 
begin 

case  XIEO(stm)  of 

when  labeled  *>  — (<<ID>>  ETM  ) 

return  nJ'1ELS_IN_STMT5TM  (stm)  , DECL_LAPEL(in(eto)  , env)); 
when  others  «> 
return  env; 
end  case 

end  LAPELS  IN  STM; 


module. 


Formal  Definition 


5-71 


Preliminary  Draft 


o 

n 

o 

o 


procedure  LAAELS_IN_STM_S (stm:  TREE;  onv:  S EMV)  return  r is 
begin 

if  I?  EMT>TY(stm_s)  then 
return  onv;  ” 
else 

return  LARELS_IN_STtf  S (TAIL  (stm  s)  , LA*»E1S  TM_ST*!  (l!?AO  (st-n  s)  , onv)); 
end  if; 

end  LA*»ELS_TN_ST?1_S; 

procedure  LAQEL?— IN1  (list:  TREE;  cnv:  S EMV)  return  S SMV  is 
begin  --  lint  is  condi  t i onol  n or  altcrnat  ivr  s 
if  is  ripTY(list)  then 
return  cnv; 
else 

return  LA**ELS_IN  (TAIL  ( 1 ist)  , LABEL?  IN  STM  <»(?TM  S ('1FAD  ( 1 1st) ) , label_s) ) ; 

end  if; 

end  LASELS_IN; 
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Dynamic  Scrrirnt  ics: 
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The  following  functions  are  used  to  associate  a continuation  with  each  label  in  the  dynamic  environment. 
<to  be  inserted) 
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6.  Declarative  Parts,  Subprograms,  and  Blocks 

A declarative  part  contains  declarations  and  related  information  that  apply  over  a region  of  program  text. 

A subprogram  is  an  executable  program  unit  that  is  invoked  by  a subprogram  call.  Its  definition  can  be  given 
in  two  parts:  a subprogram  declaration  defining  its  calling  convention,  and  a subprogram  body  defining  its 
execut ion . 

A block  allows  one  to  make  declarations  local  to  the  sequence  of  statements  where  they  are  used,  without 
introducing  a procedure.  A block  may  bo  viewed  as  an  anonymous  procedure  implicitly  called  at  the  place  of  its 
definition. 


6.1  Declarative  ®arts 


Blocks,  subprograms,  and  modules  may  contain  declarative  parts. 


declarat ive_part 

[use_clause]  (declaration)  ( reprcsentation__specif  ication)  (body) 
body  (visibil ity_restr ict ion)  unit_body  | body_stub 
unit_body  subprogram_body  I module^ specif icat ion  I modulo_body 
Abstract  Syntax: 


use  ->  NAME  S ITEM 

itrm  s ->  TTFM... 

urTTt  ->  SPECIFIER  BODY 


--  (use  NAVE  S ; ITEM  S) 

— [ITEM;  ...) 

— [SPECIFIER  18  BODY  1 


OECL  PART  : t • ns*  \ item  s 
ITEM  s : • ■ item  s 

ITEM  across  1 decl  I component  rep  I packing  | record  rep  I restricted  I 

su'oiin i t | fxp 

BODY  block  I stub  I void  I EXT  NAME 

SPECIFIER  : : ■ subprogram  1 module  T void  | generic  I family  • 

Description: 

The  successive  constituents  of  a declare*-  * vo  pert  rrc  elaborated  in  the  order  in  which  they  appear  in  the 
program  text.  Expressions  appearing  in  declarations  or  representation  specifications  (see  13)  are  evaluated 
during  this  elaboration.  A subprogram  must  not  bo  celled  within  such  an  expression  if  the  subprogram  body 
appears  later  in  the  declarative  part.  In  particular,  these  rules  apply  to  formal  parts  of  subprogram 

specifications  end  tc  constr-*1 in*s  of  obi-c^s,  typ*'*,  * nd  subtypes. 
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The  body  of  a subprogram  or  module  declared  In  the  declarative  part  of  a block  or  subprogram  must  be  provided 
in  the  some  declarative  part.  The  body  of  a subprogram  or  module  declared  in  a module  specification  must  be 
provided  in  the  corresponding  module  body.  If  the  body  of  such  a unit  is  a separately  compiled  subunit  (see 
10.2)  it  must  be  represented  by  a body  stub  at  the  place  where  it  would  otherwise  appear. 

A declarative  part  can  also  contain  a use  clause  (see  8.4). 


Static  Semantics: 

procedure  CHECK_DECL_PART (decl_par t i TREE ; env:  S ENV;  local:  S EHV)  return  TREE_ENV  is 
begin 

case  KIND(decl_part)  of 

when  use  — ■>  return  CHECK_USE (decl_par t , env); 

when  item  s »>  return  CHECK~ITEM_S (decl_part,  env,  local); 
end  case; 

end  CHECK  DECL  PART ; 


procedure  CHECK_ITEM_S (item_s:  TREE;  env:  S ENV;  local:  S ENV)  return  TREE  ENV  Is 
begin 

if  TS  EMPTY (item_s)  then 

return  TREE_ENV( itcm_s , local); 

else 

declare 

tree  env  : constant  TREE  ENV  :-  CHECK_ITEM  (HEAD(ltem_s) , env,  local); 

loc?T2  : constant  S ENV  :«  ENV  — (tree  env)7 

env2  : constant  S ENV  :*  NESTED  ENV  (env,“locel2) ; 

tree_env2:  constant  ■fftEE  ENV  :-  CHECK_TTEM_S  (TAIL)  item_s)  , env2,  loca!2); 

begin 

return  TREE_ENV(PRE(TREE(tree_env) , TREE (trec_env2) ) ; , ENV(tree_env2) ) ; 

end ; 
end  if; 

end  CHECK  ITEM  S; 


procedure  CHECK_ITEM ( i tern:  TREE;  env:  S EHV;  local:  S ENV)  return  TREE  ENV  is 

begin  - 


case  KlND(item)  of 
when  decl  ■> 

when  restricted  *> 

when  subunit  •> 

when  others  •> 

end  case; 

end  CHECK  ITEM; 


— (NATURE  DESIGNATOR  S DESCRIPTION;  1 
return  CHECK_DCCL ( l tern,  env,  local) ; 

--  (restricted  name  s decl  si 

return  CHECK-RESTRI^TED (item,  env,  local); 

— (separate  DECL;) 

return  CHECK_SURL'NIT  ( i tem,  env,  local); 

— ignored  in  this  version  of  static  semantics, 
return  TREE  ENV(itom,  local); 


procedure  DECL_UNlT(decl:  TREE;  env:  S ENV:  local:  S ENV)  return  TREE  Env  is 
designators:  constant  TREE  DESIGNATOR'S  (decl) ; 
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nature 
unit 

begin 

case  KlND(naturc)  of 


constant  TREE  :»  NATURE 
constant  TREE  :*  DESCRIPTION 


function  I 
procedure  I 
entry  I 
package 
= > 


(procedure  DESIGNATOR  S 
(procedure  DESldSNArOp  ft 
(entry  cestgi-iatoITT 
I package  designator  S 


(dccl ) 
(decl ) 


DESCRIPTION) 

DESCRIPTION) 

PFECRTPT'pSu] 

DECCPTPT-IONl 


declare 

tree  des_den  : constant  TREE  DCS  DEN 

unit?  — : constant  TREE 

den  : constant  S DEN 

tree  env  r constant  TREE  ENV 

de3ignator_s2:  constant  TREE 
beg  in 

return  .TREE  ENV (MAKE (decl , nature 
end ; 

end  case; 
end  DECL  UNIT; 


CI'ECK  UNTT  (nature . unit,  env); 

TREE ( Free_des  den) ; 

DFN(nature,  PF'S  DFM(trce  des  den)); 
CMF.CK_DESIC.NATOR_S(dcsignatoT_s,  local 
TREE ( t ree_cnv) ; - • - 

designators  2) , ENV ( t ree_env) ) ; 


den)  ; 


procedure  CHECK  UNIT(naturo:  TREE;  unit:  TREE;  env: 
tree  specif_3en  : constant  TREE  SPECIF  DEN  :• 

spccTfier  — : constant  TREE  :• 

local  : constant  S ENV  :* 

begin 

if  IS  FUNCTION(naturo)  and  SIDE  EFFECTS (BODY (uni t) 
return  no_side_efpects_in_function_body : 

else 

declare 

env2  : constant  S ENV  : 

tree_body_den:  constant  TREE  BODY  DEN  : 
body-  — : constant  TREE  : 

des_den  : constant  DF.S  DEN  : 

begin 

return  TREE  DES  DEN (HAKE (uni t , specifier, 
end; 
end  if; 

end  CHECK  UNIT; 


s ENV)  return  TREE  DCS  DEN  is 

C!!FCK_SPECIFTEP  (SPECIFIER  (unit)  , env,  EMPTY); 
TRF.E(trce  specif  den); 

LOCAL_ENvTsPECIF-DEN(treo_specif_den) ) ; 
env,  local)  then 


NESTED  ENV(cnv,  local); 
CHECK_POPY(RODY(unlt) , env2,  local): 
TREE (Tree  body  den); 

DES  DEN (SPECIF- DEM ( tree_spec i f den), 
- BODY_DEN ( t ree_body_denT) ; 

body) , des_don) : 


procedure  CHECK_SPECIFIER (specif ier : TREE;  env:  S ENV;  local:  S ENV)  return  TREE  SPECIF  DEN  is 
begin 

case  KIND(specif ier)  of 

when  subprogram  ->  — |(DECL_S)  RESULT) 

CHECK  SUBPROGRAM (spec If ier,  env,  local); 

when  module  ->  — [DECL_PART  private  DECL_PART]  v 

CHECK  MODULE (Speci f ier , env,  local); 
when  voi?  *> 

return  TREE  SPECIF  DEN (void,  EMPTY) 
when  generic  »>  - — TTdeCL_S)  SPECIFIER) 

CHECK  OENERIC(specifier,  env, “local): 
when  family  ->  — ((RANGE)  SPECIFIER) 

CHECK_FAMILV(specifier,  env,  local); 
end  case;  - 


r- 

O 

C 

o 

o 

O 

O 

O 

o 

o 

o 

c 


O' 


Formal  Definition 


6-3 


Preliminary  Draft 


end  CHECK_SPECIFIER; 


6.2  Subprogram  Declarations 


A subprogram  declaration  specifies  the  designator  of  a subprogram,  its  nature  (function  or  subprogram),  its 
formal  parameters  (if  any),  and  the  type  of  any  returned  value. 

Syntax : 

subprogram_dccl?rat ion 

subprogram_speci f icat ion; 

I subprogram~nature  designator  is  gcner ic_instant iat ion ; 

subprogram_speci f icet ion  (gener ic_clause) 

subprogrcm_nature  designator  { formal_par  tj  (return  typc_mark  (constraint) 

subprogram_no tur e procedure  I procedure 

•designator  identifier  I charactcr_str ing 

formal_part  (parameter_declaration  {;  par ameter__declarat ion) ) 
parameter  declaration 

idontf?ier_list  : mode  type_mark  (constraint)  (:»  expression) 
mode  (in)  I out  I in  out 
Abstract  Syntax : 


d^cl  ->  NATURE  DESIGNATOR  S DESCRIPTION 
unit  ->  SPECIFIER  BODY 

subprogram  ->  DECL  S F5SULT  — ( (DECL  S)  RESULT) 


RESULT  : 

DESCRIPTION  ; 

» constrainted 
■ instantiation 

void 

object 

renaming 

1 type  description 

1 unit 

1 void 

SPECIFIER  ; 

■ subprogram 

mod  u 1 e 

void 

1 generic 

1 family 

CODY  ; 

» block 

stub 

void 

| EXT  NAPE  • 

NATURE  : 

* constant 

ertry 

cxceot i on 

I function 

1 in 

1 in  out 

out 

package 

procedure 

| subtype 

1 task 

1 type  T 

variable. 

Description; 


A designator  that  is  a character  string  is  used  in  function  declarations  for  overloading  operators  of  the 
language.  Such  a string  must  denote  one  of  the  existing  operator  symbols  (see  4.5). 

A subprogram  specification  including  a generic  clause  specifies  a generic  subprogram;  an  instance  of  such  a 
generic  subprogram  is  declared  with  a subprogram  declaration  including  a generic  i nst ant iat ion  (see  12). 

A parameter  declaration  or  constraint  on  the  result  cannot  contain  an  identifier  declared  in  another  parameter 
declaration  of  the  same  formal  part. 
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Norm?!  isation: 


procedure  N,OPMALIZE_SPECIFTBR  (specif  ier:  TREE)  return  TREE  is 
begin 

— this  function  chocks  that  "a  parameter  declaration  or  constraint  on  the  result 

— cannot  contain  an  identifier  declared  in  another  parameter  declaration  of 

— the  same  formal-part”, 
end  NORMALI ZE— SPECIFIER ; 

Static  Semantics: 


o 

I 

| o 


o 


o 

I 

i o 


I 


o 

o 


procedure  CHECK  SUBPROGRAM ( subprogram : TREE;  env:  S ENV;  local:  S ENV)  return  TREE  SPECIF  DEN  Is 
env3  constant  S EMV  :•  IN  SUa*P55?.V<envl ; 

tree_env  : constant  TPEF  ENV  :*  CHFCK_DECL_S  (OECL_S (subprogram) , env2,  local): 

decl”s  : constant  TREE  :«  TREE  “ (trcc_env) : 

trcc_type_den:  constant  TREE  TYPE  DEN  :»  CHECK_RESUI.T  (P.ESULT(subprogrem)  , onv2) ; 
result  — : constant  TFFF  :»  TREE  (tree_env); 

spccif_den  : constant  E_SPECIF_DEN  : « SPECTF_DEN  (decl_s,  ENV(tree_cnv) , TYPE_DEN(tree_type_den) ) s 

begin  - 

return  TREE  SPECIE  DEN (MAKE ( subprogram , decl_s,  result),  spccif_den) ; 
end  CHECK_S'J5PR0GPAMs~ 

procedure  CHECK_RESULT (result:  TREE:  env:  S ENV)  return  TREE_TYPE_DEN  Is 
begin 

case  KtNDlresult)  of 

when  void  •>  return  TREE_TYPE_DEN ( result , TYPE_DEN(EMPTY) ) : 

when  constrained  *>  return  CHECK_TYPE  (result,  TYPE  DEN (env) ) ; 
end  case; 
end  CHECK  RESULT: 


6.3  Formal  Parameters 


The  formal  parameters  of  a subprogram  are  considered  local  to  the  subprogram.  A parameter  has  one  of  three 


modes: 

O 

in 

The  parameter  acts  as  a local  constant  whose  value 
corresponding  actual  parameter. 

is 

provided  by  the 

o 

out 

The  parameter  acts  as  a local  variable  whose  value  is 
ponding  actual  parameter  as  a result  of  the  execution 

assigned  to  the  corres- 
of  the  subprogram. 

o 

In  out 

The  parameter  acts  as  a local  variable  and  permits 
the  corresponding  actual  parameter. 

access  and  assignment  to 

If  no  mode  is  explicitly  given,  the  node  in  is  assumed.  The  components  of  in  parameters  that  are  arrays, 
records,  or  objects  denoted  by  access  values  must  not  be  changed  by  the  subprogram. 

For  in  parameters,  the  parameter  declaration  may  also  include  a specification  of  a default  expression,  whose 
value  is  implicitly  assigned  to  the  parameter  if  no  explicit  value  is  given  in  the  call.  This  expression  is 
evaluated  when  the  subprogram  specification  is  elaborated. 
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For  all  modes,  access  to  the  actual  parameters  can  be  provided  either  throughout  the  execution  of  the 
subprogram  body  or  by  copying  the  corresponding  actual  parameter  before  the  call  (in  parameters),  ?“rr  the 
call  (out  parameters)  or  both  (in  out  parameters).  The  effect  of  a subprogram  th^t  is  abnormally  terminated 
by  the  occurrence  of  an  exception  is  undefined;  its  actual  in  out  and  out  parameters  may  or  may  not  have  been 
updated . 

In  the  absence  of  aliasing  (see  5.2.3)  the  effect  of  a subprogram  call  is  the  same  whether  or  rot  copying  is 
used  for  parameter  passing,  unless  the  subprogram  execution  is  abnormally  terminated.  A program,  that  relies 
on  some  assumption  regarding  the  actual  mechanism  used  for  parameter  passing  is  therefore  erroneous. 


6.4  Subprogram  Bodies 


Syntax : 

A subprogram  body  specifies  the  execution  of  a subprogram. 

subprog ram__fcody 

subprogram  specification  is 
declarative^ par t 
begin  “ 

soqucnce_of_statements 
(exception  ” 

(except ion_handler ) 1 
end  [designator J ; 

Abstract  Syntax : 

dccl  ->  NATUPE  DESIGNATOR  S DESCRIPTION 

in  it  ->  SPECIFIER  BODY  --  (SPECTFTFR  is  BODY] 

DESCRIPTION  : : ■ instantiation  | object  I renaming  | type  description  I unit  I void 
BODY  : ;«  block  I stub  | voTj  I EXT  T?'VE 


Descript  ion : 


The  subprogram  specification  provided  in  a subprogram  body  must  be  identical  to  the  spec i f i cat  ion-  g i ven  in  the 
corresponding  subprogram  declaration,  if  both  arc  given.  A subprogram  declaration  must  be  given  if  the 
subprogram  is  defined  in  the  visible  part  of  a module,  or  if  it  is  called  by  other  subprogram  or  module  bodies 
that  appear  before  its  own  body.  Otherwise,  it  can  be  omitted  and  the  specification  appearing  in  the  body  acts 
as  a subprogram  declaration.  The  elaboration  of  a subprogram  body  consists  of  the  elaboration  of  its 
specification  unless  the  latter  elaboration  has  already  been  done. 

Upon  each  call  to  a subprogram,  the  association  between  actual  and  formal  parameters  is  established  (see  5.2), 
the  declarative  part  of  the  body  is  elaborated,  and  th»  statements  of  the  body  are  executed.  Upon  completion 
of  the  body,  assignment  to  out  and  in  out  actual  parameters  is  completed,  if  necessary  (see  6.3),  and  then 
return  i3  made  to  the  caller.  A subprogram  body  may  contain  exception  handlers  to  service  exceptions 
occurring  during  its  execution  (see  11). 

The  optional  designator  at  the  end  of  the  subprogram  body  must  repeat  the  designator  of  the  subprogram 
specification. 
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6.5  Function  Subprograms 


A function  is  a subprogram  that  computes  a value.  A function  c-^n  only  have  in  parameters  and  must  contain  a 
return  clause  specifying  the  type  of  its  returned  value.  The  statement  list  in  the  function  body  must  include 
one  or  more  return  statements  specifying  the  returned  value.  An  attempt  to  leave  a function  otherwise  than  by 
a return  statement  (i.c.  by  reaching  the  final  end)  causes  a NO_VALUE_ERROR  exception  to  be  raised. 

Side  effects,  e.g.  assignments  to  non-local  variables,  are  not  allowed  within  functions,  wh'-t-hrr  directly,  or 
indirectly  through  other  subprogram  calls.  Hence,  if  function  calls  occur  in  expressions,  they  can  be 
rearranged  in  any  order  consistent  with  the  properties  of  the  operators. 

If  a parameter  belongs  to  an  access  type,  the  parameter  must  be  viewed  as  providing  access  to  the  complete 
collection  of  dynamically  allocated  objects.  For  functions,  this  collection  is  considered  as  an  implicit  in 
parameter.  As  a consequence,  within  the  function  body  there  can  bo  no  alteration  to  any  object  designated  by 
such  a parameter  or  designated  by  a local  variable  of  the  access  typ^.  Similarly,  allocators  cannot  appear  in 
a function  body. 

Value  returning  procedures  obey  rules  similar  to  those  of  functions:  a value  returning  procedure  can  only  have 
in  parameters,  its  declaration  must  contain  a return  clause,  and  its  body  may  only  be  left  by  a return 
statement.  However,  assignments  to  global  variables  are  permitted  within  value  returning  procedures.  Calls  of 
such  procedures  <* " only  valid  at  points  of  the  program  where  the  corresponding  variables  are  not  within  the 
scope  of  their  declaration.  The  order  of  evaluation  of  these  calls  is  strictly  that  given  in  the  text  of  the 
program.  Calls  to  value  returning  procedures  are  only  allowed  in  expressions  appearing  in  assignment 
statements,  initialisations,  and  procedure  calls. 

Normal i zat ion ; 

procedure  NORNALIZE_FUNCTTONJ5PECIFIER (speci f ier : TREE)  return  TREE  is 
begin 

— this  function  checks  "A  function  can  only  have  in  parameters 

— and  must  contain  a return  clause.” 

— "A  value  returning  procedure  can  only  have  in 

— parameters,  its“declaration  must  contain  a return  clause", 
end  NORMALIZE__FUNCTIOM_RPECJFIER; 


procedure  STDE_EFFECTS (body : TREE;  env:  S ENV;  local:  S ENV)  return  BOOLEAN  is 
begin 

— <to  be  defined> 
end  SIDE_EFFECTS; 


6.6  Overloading  of  Subprograms 


The  same  subprogram  designator  can  be  given  in  several  otherwise  different  subprogram  specifications;  it  is 
then  said  to  be  ovr loaded . The  declaration  of  an  overloaded  subprogram  does  not  hide  a previous  subprogram 
declaration  unless  the  order,  names,  modes,  and  types  of  the  parameters,  and  the  result  type,  if  any,  are 
identical  in  both  declarations  (a  default  expression  for  an  in  parameter  is  ignored  here).  Such  redefinition 
is,  of  course,  illegal  within  the  same  declarative  port.  Overloaded  definitions  may,  but  need  not,  occur  in 
the  same  declarative  part. 
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A cell  to  an  overloaded  subprogram  is  ambiguous  (and  therefore  illegal)  if  the  type,  mode,  and  nam* 
information  derived  from  the  actual  parameter  associations  end  the  type  information  reouired  for  the  rerult 
ore  not  sufficient  to  identify  exactly  one  overloaded  specification.  Ambiguities  may  be  resolved  by  the  use  of 
a qualified  expression,  or  by  the  naming  of  parameters. 


6.6.1  Overloading  of  Operators 


A function  named  by  a character  string  is  used  to  define  an  additional  meaning  for  an  operator.  The 
overloading  of  operators  is  identical  to  overloading  of  other  subprograms,  except  that  the  character  string 
must  denote  one  of  the  operators  in  the  language. 

Overloading  is  permitted  for  both  unary  and  binary  operators.  A unary  operator  can  only  be  overloaded  as  a 
unary  and  a binary  as  a binary.  Overloading  does  not  change  the  precedence  of  an  operator.  Ac  overloading  of 
a relational  operator  must  have  the  result  type  BOOLEAN.  The  operator  /■  must  not  be  overloaded  explicitly, 
since  every  overloading  of  the  operator  ■ results  in  an  implicit  overloading  of  /« . 


6.7  Blocks 


A block  introduces  a sequence  of  statements,  optionally  preceded  by  a governing  declarative  part. 

Syntax ; 

block 

(declare 

declarative_par t] 
begin 

seouence_of  statements 
(exception  “ 

{exception  handler)! 
end  ( ident i fTer ] ; 

Abstract  Syntax ; 

block  ->  DECL  PART  STM  S ALTERNATIVE  S — (declare  PECL_PART  begin  STM_S  exception  ALTERNATIVE^  endl 
Dcscr ict Ion: 

Execution  of  a block  results  in  the  elaboration  of  its  declarative  part  followed  by  the  execution  of  the 
sequence  of  statements.  A block  may  also  contain  exception  handlers  to  service  exceptions  occurring  in  the 
block  (see  11).  If  a block  is  labeled,  the  optional  identifier  appearing  at  the  end  of  the  block  must  repeat 
the  label, 

St *t je  r"C3nt i cs : 

procedure  CHECK  BLOCK (block:  TREE;  env:  S ENV;  local:  S ENV)  return  TREE  is 

tree_env:  constant  TREE_ENV7^  CHECK  DtfCL_PAPT (DECL  PAR*  (block)  , env,  local); 
beg  in  ~ ” “ 

if  PODTES  PROVIDED (ENV (tree  env))  then 
declare 
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7.  Modules 


o 

o 


A program  can  be  composed  of  program  units  of  three  kinds.  These  arc  subprograms  and  two  forms  of  modules, 
package  modules  and  task  modules.  This  chapter  describes  the  common  properties  of  package  end  task  modules 
and  the  few  specific  properties  of  package  modules.  The  specific  properties  of  task  modules  are  described  in 
Chapter  9. 


o 

o 


Modules  allow  the  specification  of  groups 
represent  pools  of  common  data  and  type 
related  subprograms  and  encapsulated  data 
users. 


of  logically  related  entities.  In  their  simplest  form  modules  can 
declarations.  In  addition,  modules  con  be  used  to  describe  groups  of 
types,  whose  inner  workings  are  concealed  and  protected  from  their 


o 


7.1  Module  Structure 


o 

o 

o 

o 

o 

o 

o 

G 


o 


A module  is  generally  provided  in  two  parts:  a module  specification  and  a module  body  with  the  same 
identifier.  The  simplest  forms  of  modules,  those  representing  pools  of  data  and  types,  do  not  require- a 
module  body. 

Syntax : 

module_declarr t ion 

(visibi  J ity__ccstcict  ion!  tPodu2e~specif  Icet  ion 
I modulc_neturc  identifier  ( (disc"rote_  range)  ] is  gencr  ic^instant  i at  ion ; 

module^ spcci f ica tion 
[gencr ic_cl a use  I 

module_noture  identifier  [ (d iscrete__r ange)  ) (is 
declara  t ive__par  t 

(private 

declarative_par t] 
end  ( identifier] j 


module_nature  package  I task  *.  •' 
module  body 

mooulc_nnture  body  identifier  is 
declarat i ve_ par  t 
[begin 

sequcnce_of_statements] 
[exception  ~ 

(exception  handler J( 
end  ( identi fieri ; 
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begi 

r 

end ; 
else  MI 
end  if; 

end  CHECK 


nv2  t constant  S ENV  :=  LA°FL'?__TN>_STM_>S  (STM_S  (block)  , ENV  ( troe_env)  ) ; 

nv3  ! constant  S“ENV  :=  NESTED~ENV  “ (envT  env2); 

tm  s : constant  Tprr  :*  CHECK  STM  S (STM  S (block)  , env3)  ; 

1 t“rnativc_c:  constant  TRE:n  t*  CMECK~MA.NDLER_S  (!!ANOLFP_S  (block)  , cnv3)  ; 

n 

eturn  MAKE  (block , TREE  (tree*  cnv)  , stm  s,  alternatives); 


SSTNO^BODIFS; 


procedure  BODIES_PROVIDEO (rnv : S ENV)  return  BOOLEAN  is 
begin 

--  this  function  verifies  that  the  body  of  a subprogram  or  module 
--  declared  in  the  declarative  part  of  a block  or  subprogram  must 
— is  orovided  in  the  same  declarative  part, 
end  BODIES  PROVIDED; 
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Abstract  Syntax : 

dec!  ->  NATURE  DESIGNATOR  S DESCRIPTION 

unit  ->  SPECIFIER  ROPY 

module  ->  DPCL  PART  DECL  PART  — fis  DECL  PART  private  DPCL  PART] 

f-  ni  ly  ->  fAaC?  frfrScTFfg*  — [ (r*ng£)  5T!Ttftepi 


SPECIFIER 

P.GDY 

nr.scRIPT  CON 


r » subprogram  I modul  o I void  I g^ner  i c I f ami 1 y 

:•  bi ock  I stub'  I voH  I rxT  x,vip  ' 

:«  7nrt.?ofiation  I oh ject  I ron  ■'ring  | type  orr.cr  1 Pt  i on  I un  i t I voi  d 


Poser i pt ion : 

A modulo  specification  contains  a declarative  part  called. th"  visible  part  and  an  optional  declarative  pert 
called  the  private  pert.  Elaboration  of  a module  declaration  results  in  the  elaboration  of  these  declarative 
parts  and  therefore  in  the  allocation  of  the  variables  of  the  module  specification  and  the  assignment  of  any 
initial  values. 

A module  specification  with  a generic  clause  defines  a generic  module.  Instances  of  generic  modules  can  be 
obtained  by  module  declarations  including  e generic  instantiation  (see  12). 

A module  declaration  may  include  a discrete  range  after  the  identifier.  This  only  applies  to  task  modules  and 
the  identifier  then  denotes  a family  of  tasks. 

The  elaboration  of  a task  body  has  no  other  effect.  The  cl  eborc-'t  ion  of  its  declarative  part  and  the  execution 
of  its  seguence  of  statements  is  caused  by  the  execution  of  an  initiate  statement  (sec  9.3).  The  elaboration 
of  a package  body  causes  the  elaboration  of  its  declarative  part  and  the  execution  of  the  reguencc  of 
statements,  if  any.  These  statements  can  be  used  to  achieve  further  initializations. 

Module  bodies  and  the  visible  parts  of  packages  may  contain  further  module  doc  1 nrat ions . The  body  of  ary  unit 
declared  in  a module  spec! f i cat  ion  must  appear  in  the  corresponding  module  body. 

Static  Semantics: 


procedure  CHECK  MODULE (module : TREE;  env:  S ENV ; local:  S ENV)  return  TREE  SPECIF  DEN  is 
tre?_"rw  : constant  T9EF.  E”V  CnBCK_DECL_PART  (DrCL_PAFTl  (stodulc)  , env,  local); 

env  2"”  : constant  S ENV  :*  NESTED  ENV  (env  , “ENV  ( tree  env)); 

tree  mv2  : constant  TPEF._ENV  :■  CHECK J5CCI._P ART (0FCL_DART2  (mot?u  1 c)  , cnv2,  FNV( tree_cnv) ) ? 
loca T2  : constant  S ENV  :■  REMOVE  ~ (CUV(trec  env),  local); 

soeci f_den:  constant  S~SPECIFJ)EN  :«  SPECIFJ3EN  (VI^TRLB (Tocal 2) , fkv ( trec_cnv2) ) ; 

begin 

return  TPEE  SPECIF  DEN  (MAKE  (module , TREE(trec  envl),  TREE  (tree  env2)),  specif*den); 
end  CHECK  MODULE; 


— the  constraint  "the  batches  of  the  specified  units  must  appear  within 

— the  declarative  part  of  the  module  body"  is  checked  by  C1IECK_8L0CK  (see  Section  6.7). 

procedure  REMOVE (envl , env2:  S_ENV)  return  S_ENV  is 
begin 

--  This  procedure  builds  a new  environment  of  type  S_F.NV  that 

— includes  designators  declared  in  envl  and  not  in  cnv7. 

--  it  is  used  to  build  the  environment  defined  by  the  visible  part 

— of  the  module, 
end  REMOVE? 
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The  first  declarative  part  of  a module  specification  is  celled  its  visible  part.  The  entities  declared  in  the 
visible  part  can  be  made  visible  to  other  program  units  by  means  of  a use  clause  (sec  8.4)  or  selected 
components  (see  4.1.2).  A module  consisting  of  only  a module  specification  (i.e.,  without  n module  body)  can 
be  used  to  represent  a group  of  common  constants  or  variables,  or  a common  pool  of  dat*  and  types. 

The  visible  port  contaii s all  the  information  that  another  program  unit  is  able  to  know  about,  the  module. 


7.3  Module  Bodies 


The  visible  port  of  a module  may  contain  the  specification  of  subprograms  or  the  specification  of  other 
modules.  In  such  cases,  the  bodies  of  the  specified  units  must  appear  within  the  declarative  part  of  the 
module  body.  This  declarative  part  can  also  include  local  declarations  and  local  program  units  needed  to 
implement  the  visible  items. 

In  contrast  to  the  entities  declared  in  the  visible  part,  the  entities  declared  in  the  module  body  are'  not 
accessible  outside  the  module.  'Vs  .?  conseouence,  a module  with  ? module  body  can  be  used  for  the  construction 
of  a group  of  related  subproaroms  (a  package  in  the  U3ual  sense),  where  the  logical  operations  accessible  to 
the  user  are  clearly  isolated  from  the  internal  entities. 


7.4  Private  Type  Declarations 


The  structural  details  of  some  declared  types  may  be  irrelevant  to  their  logical  use  outside  a module.  This 
may  be  accompl ished  by  providing  a private  type  declaration. 

Syntax : 


pr  ivate_type_declarat  ion 

(restricted)  type  identifier  is  private; 

Abstract  Syntax ; 

restricted  private  -> 


Poser iot ion : 

A private  type  declaration  can  only  appear  in  the  visible  part  of  a module.  The  full  declaration  of  the 
private  type  must  appear  in  the  private  port  of  the  module  specification.  Such  types  are  called  private  types. 

For  a private  type  (not  designated  as  restricted),  the  only  information  available  to  other  program  units  is 
that  given  in  the  visible  part  of  the  defining  module.  »*ence,  the  name  of  the  type  and  the  operations 
specified  in  this  visible  part  are  available.  In  addition,  assignment  end  the  predefined  comparison  for 
equality  or  ineouMity  are  available  (unless  a redefinition  of  equality  hides  the  predefined  equality  and,  as 
a consequence,  also  redefines  inequality). 
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These  arc  the  only  externally  available  operations  on  objects  of  a private  type.  External  units  can  declare 
objects  of  the  private  type  and  apply  available  oporaMons  to  the  objects.  In  contrast,  external  units  cannot 
access  the  structural  details  of  objects  of  private  types  directly. 

A constant  value  of  a private  type  can  be  declared  in  th*  visible  port  as  a deferred  constant.  Its  actual 
value  must  be  specified  in  the  private  part  by  redcclsring  the  constant  in  full. 

Assignment  and  the  predefined  comparison  for  equality  or  inequality  ere  not  available  for  private  type 
declarations  containing  the  reserved  word  restricted.  Thus  if  a type  is  restricted,  tho  only  operations 
available  on  objects  of  the  type  are  those  defined  by  th~  subprograms  declared  in  the  visible  part.  A user  can 
of  course  define  subprograms  calling  the  visible  operations. 
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8.  Visibility  Rules 


This  charter  describes  the  rules  defining  th*  scope  of  dec) ar at  ions  end  the  rules  defining  which  identifiers 
are  visible  at  various  points  in  the  text  of  th0  program.  These  rules  are  stated  here  as  applying  to 
identifiers.  They  apply  equally  to  character  strings  used  <■»*•  function  designators  or  enumeration  literals. 

A declaration  associates  an  identifier  with  a program  entity,  such  as  a variable,  a typ*»,  a subprogram,  a 
formal  parameter,  a record  component,  etc.  The  region  of  text  over  which  a declaration  has  an  effect  is  called 
the  scope  of  a declaration. 

The  same  identifier  can  be  introduced  by  different  declarations  in  the  text  of  a program  and  thus  be 
associated  with  alternative  entities.  Hence  the  scopes  of  several  declarations  with  the  same  identifier  can 
overlap. 

Overlapping  scopes  for  declarations  with  the  same  identifier  can  occur  because  of  overloading  of  subprograms 
or  of  enumeration  literals  (see  6.6  and  3.5.1).  Overlapping  scopes  can  also  occur  because  of  nesting.  In 
particular,  subprograms,  modules,  and  blocks  can  be  nested  within  each  other;  similarly  these  units  can 
contain  nested  record  type  definitions  or  nested  loop  statements. 

At  a given  point  of  text,  the  declaration  of  an  entity  with  a certain  identifier  is  said  to  be  visible  if  this 
entity  is  an  acceptable  meaning  for  an  occurrence  of  vie  identifier. 

For  overloaded  identifiers,  there  can  be  several  meanings  acceotablo  at  a given  point,  and  the  ambiguity  must 
be  resolved  by  the  rules  of  overloading  (see  4.6  and  6.6).  For  other  identifiers  (the  usual  case  and  the  case 
considered  in  this  chapter)  there  can  be  at  most  one  acceptable  meaning.  Hy  convention,  an  identifier  is  said 
to  be  visible  if  its  declaration  is  visible.  The  visibility  rules  are  the  rules  defining  which  identifiers  arc 
visible  at  various  points  of  the  text. 


8.1  Scope  of  Declarations 


Entities  can  be  introduced  by  declarations  in  various  ways.  An  entity  can  be  declared  in  a declarative  part  of 
a block,  subprogram,  or  module.  An  enumeration  literal  is  declared  by  its  occurrence  in  an  enumeration  type 
definition,  a loop  parameter  by  its  occurrence  in  an  iteration  specification.  Finally,  entities  can  be 
declared  as  record  components  or  as  formal  parameters  of  subprograms,  entries,  and  generic  clauses. 

The  scopes  of  these  various  forms  of  declarations  and  the  scope  of  labels  are  defined  as  follows: 


- The  scope  of  a declaration  given  in  the  declarative  part  of  a block,  subprogram  body,  or  module  body 
extends  from  (and  includes)  the  declaration  up  to  the  end  of  the  corresponding  block,  subprogram,  or 
module . 

- The  scope  of  a declaration  given  in  the  visible  or  private  part  of  a module  extends  from  (and  includes) 
the  declaration  to  the  end  of  the  module  specification.  It  also  extends  over  the  corresponding  module 
body. 
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The  scope  of  a declaration  given  in  the  visible  p*rt  of  a module  also  extends  to  the  ®nd  of  the  scope  of 
the  module  declaration  itself. 


- The  scope  of  an  enumeration  literal  is  th®  scope  of  the  enumeration  type  declaration  (or  definition) 
itself. 

- The  scope  of  a record  component  extends  from  the  compon®n*-  declaration  to  tb®  end  of  the  scope  of  the 

record  type  declaration  (or  definition)  itself. 

- Th®  scope  of  an  (unnamed)  enumeration  or  record  type  definition,  itself  given  within  a record  type 
definition,  extends  to  the  end  of  the  scope  of  the  enclosing  definition  (or  declaration). 

- The  scope  of  a formal  parameter  of  a subprogram,  entry,  or  generic  clause  extends  from  the  parameter 

declaration  to  the  end  of  the  scope  of  the  declaration  of  the  subprogram,  entry,  or  generic  unit  itself. 

- The  scope  of  a loop  parameter  extends  to  the  end  of  the  cor  responding  loop. 

The  scope  of  a label  extends  from  the  first  occurrence  of  a label  to  the  end  of  the  innermost  enclosing 

compound  statement,  subprogram,  or  module.  The  first  occurrence  of  a label  can  be  either  th®  label  itself 
or  its  use  in  a goto  statement. 
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As  defined  in  the  previous  section,  the  scope  of  a declaration  always  extends  at  least  until  the  end  of  the 
language  construct  enclosing  the  declaration  (either  a block,  a subprogram,  an  accept  statement,  a module,  a 
record  type  definition,  or  a loop  statement).  In  addition,  the  scope  extends  outside  the  enclosing  construct 
for  record  components,  formal  parameters,  and  items  declared  in  a module  visible  part. 

The  declaration  of  an  identifier  is  visible  at  a given  point  'of  text  if  this  point  is  within  the  construct 
enclosing  Jts  declaration,  but  not  within  an  inner  construct  containing  another  declaration  with  the  s»me 
identifier.  An  entity  that  is  visible  in  this  manner  is  directly  visible,  that  is,  it  can  b®  named  simply  by 
its  ident  i f icr . 

An  entity  declared  in  an  enclosing  construct  is  said  to  be  hidden  within  an  inner  construct  containing  another 
declaration  with  the  same  identifier.  A subprogram  declarat ion  hides  another  subprogram  only  if  their 
spec i f ica t ions  are  equivalent  with  respect,  to  the  rules  of  subprogram  overloading  (3®®  6,f»).  An  enumeration 
literal  overloads  but  does  not  hide  another  enumeration  literal.  Pedccleret ion  (as  oppose*  to  overloading)  is 
not  allowed  within  the  same  declaration  list  or  component  list. 

The  name  of  an  entity  declared  immediately  within  a subprogram  or  module  can  always  be  written  as  a selected 
component  within  this  unit,  whether  it  is  visible  or  hidden.  The  name  of  the  unit  (which  must  be  visible)  is 
then  used  as  a prefix.  Thus,  component  selection  has  the  effect  of  opening  the  visibility  for  th®  occurrence 
of  the  identifier  after  the  dot. 

Outside  its  construct  enclosing  its  declaration,  but  within  its  scope  a record  component,  a formal  parameter, 
or  an  item  of  a module  visible  part  con  bo  made  visible  as  follows: 

- A record  component  is  made  visible  by  a selected  component  whose  prefix  names  a record  of  the 
corresponding  typ®.  It  is  also  visible  as  a choice  in  ftn  aggregate  of  the  type. 

- A formal  parameter  of  a subprogram,  entry,  or  generic  clause  is  visible  within  named  parameter 
associations  of  corresponding  subprogram  calls,  entry  calls,  or  generic  instantiations. 
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- An  entity  declared  within  a module  visible  part  is  made  visible  by  a selected  component  whose  prefix 
names  the  module.  It  may  also  be  made  directly  visible  via  a use  clause  (see  9.4). 

Pest  r let  ions  on  red^c*  arat ions ; 

An  identifier  used  tas  opposed  to  being  declared)  in  one  declaration  in  a declaration  (or  component)  list  may 
not  be  rcdcclared  in  subsequent  declarations  of  the  same  list. 

A variable  or  constant  of  an  enumeration  type  cannot  hide  an  enumeration  value  of  the  type.  The  same 
restriction  applies  to  a par ameter less  function  returning  a result  of  on  enumeration  type. 


8.3  Restricted  Program  Units 

By  means  of  a visibility  restriction,  a program  unit  may  restrict  the  visibility  it  otherwise  has  of  outer 
units. 

Syntax 

visibil ity_restr iction  restricted  fvisibil ity_l 1st) 
visibil i t y 1 1st  ::•  (unit  name  (,  unit  name)) 


Abstract  Syntax : 


restricted  ->  NAME  S DECL  S 
name  s ->  NAME  . . . 

NAME  S : : - name  s 

Poser iptlon: 


I restricted  name  s decl  S ] 
i NAME  , ...  1 “ 


In  all  cases,  the  predefined  identifiers  are  visible  within  the  restricted  program  unit.  If  no  visibility 
list  is  given,  no  other  identifiers  are  visible.  If  thor^  is  a visibility  list,  the  first  name  can  (but  need 
not)  be  the  name  of  a unit  enclosing  the  restricted  unit.  Entitles  declared  within  the  enclosing  unit  (if 
given)  are  visible  as  usual.  Other  names,  if  given,  must  be  the  names  of  modules  that  are  outside  the  given 
enclosing  unit  or  the  restricted  unit  itself.  These  module  names  are  also  visible,  and  thus  can  be  used  in 
selected  components  and  use  clauses. 


The  outer  modules  could  be  library  modules.  A module  body,  whether  restricted  or  not,  always  sees  the  visible 
part  and  the  private  part,  if  any,  of  its  own  module  spec  l f i rat  ion . Within  a restricted  program  unit,  a 
visibility  restriction  may  be  locally  superseded  by  another  visibility  restriction  given  for  an  inner  unit. 


Static  Semantics: 


function  CMECK_PESTPTOTED (restricted: 
trce_env  T constant  TREE  ENV  :• 

name“s  : constant  TREE  :■ 

env2“  : constant  i r.*iv  :• 


TREE?  env:  s puv?  loccl:  s fnv)  return 
CI!ECK_RESTRICT_NAME(NAME_S  (restricted)  , 
TREP.  (Tree_env)  ? 

ENV  i*ree"rnv)j 


TPEE  ENV 
env)  ? 


is 
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trce_env2  : constant  TP  RE  ENV  :-  CHFCK_DECL (DECL_S ( rostr icted) , onv2,  local)  ; 

dccl”s  » constant  TREE  :•  TREE (treo^env? ) 7 

locaT2  : constant  S ENV  :•  ENV  (tree~onv2); 

begin 

return  TREE  ENV(MAKE  ( restr  ictcd  , name^s,  dccl__s)  , loc*12>; 

end; 

procedure  CHECK_RESTRICT_NAME  (n*me__s:  TPFE;  env:  S ENV)  return  TREE  ENV  is 

begin 

if  IS  EMPTY (name  s)  then 

return  TREE  ENV (name  s,  EMPTY); 
elsif  IS_ENCLOSINr,(HEADlname_s)  , Cnv)  then 
declare 

env2 : constant  S ENV  RESTRICT_ENV (HEAD (rome_s) # cnv); 
begin 

return  CHE0K_RESTRTCT_NAMR2  (TAIL  (name__s)  , env2)  ; 
end; 

else  return  CHECK  RESTRICT  HAME2(nsme  s,  cnv); 
end  if; 

end  CHECK_RESTRICT_NAME; 

procedure  RESTRICT_ENV (name : TREE;  env:  S ENV)  return  S ENV  is 
beg  in 

--  This  function  hides  everything  but  the  entities  declared 

— within  the  enclosing  unit  specified  by  "name", 
end  RESTPICT^ENV; 

procedure  CW£CK_RESTRICT_NAMB2 (name_s:  TREE;  env:  S ENV)  return  S env  is 
begin 

if  rs_F'lPTY (name_s)  then 

return  TREE  EMVfneme  s,  env); 

. elsif  I S_MODULE (DEN_OF (HEAD (namc_s) , cnv))  then 
declare 

env2  : constant  ENV  :■  RESTRICTED  OP(”EAD(name  s) , env); 
trcc_env:  constant  'I  PT:r  ENV  CHE0K_RESTRICT_NAMr2  (TAIL  (naire_s)  , cnv2)  ; 
begin 

return  TREE_ENV (PRE (MEAD (name  b) , TREE ( tree_env) ) , 

” ENV  ( t ree__onv)  T ; 

end; 

else  return  TREE_CNV (MODULE  NAME  EXPECTED,  env); 
end  CHEC,<__RESTRTCT_NAME2; 

function  RESTRICTED_OP (name:  TREE;  env:  5 ENV)  return  5 ENV  is 
begin 

— This  function  makes  the  name  "name"  visible  in  the  environment  "env". 
end  RESTRICTED  OP; 


o 

8.4  Use  Clauses 


If  the  name  of  a module  is  visible  at  a given  point  of  text,  the  identifiers  declared  within  the  visible  part 
of  the  module  can  be  denoted  by  selected  components.  In  addition,  these  identifiers  c?n  be  made  directly 
visible  by  means  of  a use  clause  at  the  start  of  a declarative  part. 
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uso^clause  :*»  use  module  name  (,  module  name) r 


Abstract  Syntax : 

use  ->  NAM  S ITEM  S — ( use  NAME  S;  ITF.M  S 1 

naae  s ->  NAM ...  — ( NAMF  , . . . J 

Poser iot ion : 

The  na^ios  appearing  in  the  uso  clause  must  be  visible  module  names. 

In  order  to  define  the  sot  of  identifiers  that  arp  made  visible  by  use  clauses  at  a given  point  of  the  text, 
consider  the  cct  of  modulo  n?mc3  appearing  in  the  use  clauses  of  the  current  and  all  enclosing  units,  up  to 
the  innermost  enclosing  restricted  unit. 

An  identifier  is  made  visible  by  a use  clause  if  it  is  defined  in  the  visible  part  of  one  and  only  one  of 
these  modules  and  if  it  is  not  visible  otherwise. 

Several  overloaded  identifiers  (subprograms  or  enumeration  literals)  can  be  made  visible  by  use  clauses  as 
long  as  none  of  them  constitutes  a redefinition  of  an  otherwise  visible  identifier  or  of  an  identifier  of 
another  module  in  the  set. 

Thus  an  identifier  made  visible  by  a use  clause  can  never  hide  another  identifier  although  it  may  overload  it. 
If  an  identifier  appears  in  several  used  modules  or  is  otherwise  visible,  the  entity  cor r esoond i ng  to  its 
definition  in  one  of  the  modules  must  still  be  d'-not^d  as  a selected  component.  Renaming  and  subtype 
declarations  may  help  avoiding  excessive  use  of  selected  components. 

Stat i c Semantics: 

procedure  CHEC?C_USE  (use:  TPFF , env:  S FMV)  return  TPPF_FNV  is: 
trre_envl:  constant  TPi  F r,NV  ••  USR_F.NV  (NAME_5  (uso)  , env); 
name's  : constant  TPrr  :■  NAMF_ G Ttree^envl); 

onvl“  : constant  S ;:*V  :»  ENV  (treo^envl); 

trep_env2:  constant  TPFF  ENV  CllFCK_TTEM_S ( TTFM^S (usp) , onv2,  EMPTY); 
item_s  : constant  T>- F.r.  ••  TPEE  ” “ (tree'env2); 

cnv2  : constant  FliV  :■  ENV  (traa'nnv?)  ; 

begin 

return  TREE  CNV( MAKE  (use , name_s,  item  s) , env?.) ; 
end  0?ECKJJSF;~ 

procedure  USE_ENV (name_s : TREE;  env:  S_ENV)  return  TREE_ENV  is 
begin 

if  IS_EMPTY (n*me_s)  then 

return  TREE  ENVfnam.e  s,  env); 

elsif 

IS  "ODULE (DEN_OP (HEAD (name_s) ) ) then 
declare 

3pecif__den:  constant  S SPECIF  DEN  :•  SPFCIP^DEV  (DEN^O**  (HEAD  ( name  rs)  , env)); 
env2  ” s constant  S P’W  :•  USE  OPfrnv,  VI^TPT.E  (soec  i f 3en) ) ; 

tree_env  : constant  Tf<S^  ENV  USF”fnv (TATL (name  s),’env2T: 

begin 

return  TPEF  ENV (PRF (HEAD (name  s)  , TPFF(tree  env)), 

ENV (tree  env)T; 
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end? 

else 

return  TPEE  ENV (MODULE  NAME  EXPECTED,  env); 
end  if? 
end  USE_CNV? 

procedure  USE_OP (cnvl , cnv?:  s E»*V)  return  £ ENV  is 

envl_partl“  constant  HALF  E E??V  SURROUNDING (envl ) ? 

cnv2“earM:  constant  rM.F  s ENV  : * SURROUNDING  (rrv2 ) ? 

cnvl~pert2:  constant  f,"f.r  G env  :»  IMPCPTEO (rnvl ) ? 

env_pert2  : constant  male  r r.vy  :»  MERGE  (envl_pcrt2,  env2_pnrtl)? 

begin  ” 

return  S ENV(cnvl  parti,  cnv  port?)? 
end  USE_OP?“ 

procedure  MERGE  (ha  1 f__envl  , helf_rnv2:  HALP_S_ENV)  return  HALF  S ENV  is 
begin 

--  rto  be  defined) 
end  MERGE  ? 


8.5  Renaming 


A renaming  declaration  associates  a local  name  with  an  entity. 


rcnnmi ng_decl oration 

identifier  : type_mark  renames  name? 

I identifier  : exception  renames  name? 

( subprogr.sm_nature  designator  renames  ( name . J designator ? 

I module^nature  identifier  renames  name? 

Abst r act  Syntax : 

renaming  ->  PE?? a ME  SPEC  rVT  NAMr  --  f RENAME J5PEC  renames  EXT^NAME;  1 

REM  Vi F SPEC  : : ■ subprogram  | void  J TYPE 

FXT  M*ME  : : - NAME  I selected  string  f string 

Qe-.cr irt ion; 

The  identity  of  the  item  following  the  reserved  word  renames  is  established  when  the  renaming  declaration  Is 
elaborated.  The  newly  declared  identifier  (or  designator)  takes  on  the  seme  properties  (such  as  constancy, 
parameter  types,  and  constraints,  etc.)  as  the  renamed  entity. 

A label  cannot  be  renamed.  An  entry  can  only  be  renamed  eg  a procedure.  A subtype  can  effectively  be  used 
for  ren9itin g types  as  Jn 

subtype  ST  Is  S.T; 

Renaming  may  be  used  to  resolve  name  conflicts  (8»e  example  in  section  8.4),  to  achieve  partial  evaluation  and 
to  act  a3  a shorthand. 
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10.  Program  Structure  and  Coirpilation  Issues 


This  chapter  describes  the  overall  structure  of  programs  and  the  facilities  tor  separate  compilation  of  their 
parts.  A program  is  a collection  of  one  or  more  compilation  units.  These  can  be  subprogram  bodies,  module 
specifications,  or  module  bodies.  The  body  of  a unit  declared  within  another  unit  can  be  separately  compiled 
as  a subunit. 


o 

o 
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10.1  Compilation  Units 

A program  can  be  compiled  as  a single  compilation  unit  or  it  can  be  submitted  to  the  compiler  as  a succession 
of  compilation  units.  One  compilation  can  consist  of  several  such  units.  The  compilation  units  of  a program 
are  said  to  belong  to  a program  library. 
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Syntax 

compilation  { compi lat ion_unit } 

compilation  unit 

( visi bilTty_restr ict ion) [separate]  unit_body 
Abstract  Syntax ; 

restr i ctrd  ->  NAME  S DECL  S — [ restricted  NAME_S  DECL_S  ] 
separate  ->  — j separate  ] 

Descr ict ion: 

Each  compilation  unit  is  in  effect  a restricted  program  unit.  In  the  absence  of  an  explicit  visibility 
restriction,  an  empty  visibility  list  is  assumed.  The  visibility  rules  that  apply  to  compilation  units  follow 
from  those  that  apply  to  all  restricted  program  units  (see  n.3).  In  particular,  a separately  compiled  unit 
that  makes  use  of  a separately  compiled  module  must  name  that  module  in  its  visibility  list.  These 
dependencies  between  units  have  an  influence  on  the  order  of  compilation  and  recompilation  of  compilation 
units. 
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All  compilation  units  (that  are  not  subunits)  belonging  to  the  same  program  library  must  have  different  names. 

A compilation  unit  that  is  a subprogram  body  can  be  a main  program  in  the  usual  sense.  The  means  by  which 
main  programs  are  executed  are  not  within  the  language  definition. 

The  following  three  compilation  units  define  a program  with  an  equivalent  effect  (the  broken  lines  between 
compilation  units  are  here  to  remind  the  reader  that  thos°  units  need  not  be  contiguous  texts). 

Note  that  in  the  latter  version,  the  package  D is  (implicitly)  a fully  restricted  program  unit.  Hence,  it  has 
no  visibility  of  outer  identifiers  other  than  the  predefined  identifiers.  In  particular,  D does  not  depend  on 
any  identifier  declared  in  PROCESSOR  and  hcnc*-  can  be  from  PROCESSOR. 
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The  procedure  PROCESSOR  is  also  a restricted  unit,  but  must  name  D in  its  visibility  list  in  order  to  contain 
a legal  use  clause  for  D. 

These  three  compilation  units  can  be  submitted  in  one  or  more  compilations.  For  example,  it  is  possible  to 
submit  the  package  specification  and  the  package  body  in  a single  compilation. 


10.2  Subunits  of  Compilation  Units 


The  body  of  a subprogram  or  module  declared  in  the  outermost  declarative  part  of  another  compilation  unit  (or 
subunit)  can  bo  separately  compiled  and  is  then  said  to  be  a subunit.  Within  the  subprogram  or  module  where  a 
subunit  is  declared,  its  body  represented  by  a body  stub  at  the  plac^  where  the  body  would  otherwise 
appear.  This  method  of  splitting  a program  permits  hierarchical  program  development. 


Syntax: 

body_stub 

“subprogrem_specif icat ion  is  separate; 
f module_naturc  body  identifier  is  separate; 

Abstract  Syntax : 

stub  ->  --  [ is  separate  1 

Dee.cr  i or  ion : 

A subunit  is  said  to  be  enclosed  by  the  compilation  unit  where  its  stub  is  given.  Transi t ively,  a subunit  of  a 
subunit  of  a unit  is  also  said  to  be  enclosed  by  the  unit. 

The  body  of  a subunit  must  have  a visibility  restriction,  itself  followed  by  the  reserved  word  separate  (see 
10.1).  The  first  name  appearing  in  the  visibility  list  must  be  th«  name  of  an  enclosing  compilation  unit.  The 
name  of  a subunit  is  local  to  its  immediately  enclosing  unit.  In  consequence,  several  subunits  of  the  same 
name  can  exist  within  a program  library. 


In  the  above  example,  0 and  D are  subunits  of  TOP  (TOP  encloses  Q and  D) ; G is  a subunit  of  D (D  encloses  G 
and  similarly  TOP  encloses  G) . The  visibility  list  of  G must  mention  TOP  since  G accesses  the  type  REAL 
(mentioning  D instead  of  TCP  would  not  be  enough) . 

Note  that  the  visibility  lists  in  the  split  version  are  established  in  such  a manner  that  the  same  identifiers 
are  visible  at  all  program  points  as  in  the  initial  version.  For  example,  the  variables  R and  S declared  in 
TOP,  the  constant  PI  declared  in  the  visible  part  of  D and  the  other  entities  declared  in  the  package  body  0 
are  all  visible  within  the  s'-nuenco  of  statements  of  the  subunit  G. 


10.?  Order  of  Compilation 


The  visibility  rulrs  th**t  ■••rely  to  compilation  units  (whether  subunits  or  not)  are  the  usual  rules  that  apply 
to  all  restricted  program  units. 

The  rules  defining  th'*  order  in  which  units  can  be  compiled  arc  direct  consequences  of  the  visibility  rules.  A 
unit  must  he  compi.l'’d  after  all  compilation  units  whose  names  appear  in  its  visibility  list  or  in  the 
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visibility  list  of  any  textually  nested  subprogram  or  module,  A module  body  must  be  compiled  after  the 
corresponding  module  specification.  The  subunits  of  a unit  must  be  compiled  after  the  unit. 

Consistent  with  the  partial  ordering  defined  above,  the  compilation  units  of  a program  can  be  compiled  in  any 
order . 

^ In  the  previous  examples: 
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(a)  The  package  body  D must  be  compiled  after  the  corresponding  package  specification  (example  lb). 

(b)  The  specification  of  the  package  D must  be  compiled  before  the  procedure  PROCESSOR . On  the  other  hand, 
the  procedure  PROCESSOR  can  be  compiled  either  before  or  after  the  package  body  D. 

(c)  The  procedure  QUADRATIC_EQUATTON  (example  2)  must  be* compiled  after  the  library  modules  WAT1!_ LTB  and 

INPUT  OUTPUT  that  appear  in  its  visibility  list.  Similarly  (example  3a)  the  procedure  TOP  must  be 

compiTed  after  the  library  module  INPUT_OUTPUT  that  appears  in  the  visibility  list  of  the  nested 

procedure  G.  On  the  other  hand,  in  example  3b  TNPUT_OUTPUT  could  be  compiled  after  TOP. 

(d)  The  subunits  Q and  D (example  3b)  must  be  compiled  after  the  compilation  unit  TOP.  Similarly  the  subunit 

G must  be  compiled  after  the  enclosing  unit  D.  Note  also  that  the  library  module  INPUT  OUTPUT  must  be 

compiled  before  G. 


Similar  rules  apply  for  recompilations.  Any  change  in  a given  compilation  unit  can  only  affect  its  subunits 
and  other  compilation  units  mentioning  the  unit  in  their  visibility  lists.  Hence  the  potentially  affected 
units  need  to  be  recompiled.  An  implementation  may  be  able  to  reduce  the  recompilation  costs  if  it  can  deduce 
that  some  of  the  potentially  affected  units  are  not  actually  affected  by  the  change. 


Note  that  the  subunits  of  a unit  can  always  be  recompiled  without  affecting  the  unit  itself.  Similarly, 

; — changes  in  a module  body  do  not  effect  other  (non-nestod)  units,  since  these  units  only  hove  access  to  the 

! visible  part  of  th'e  module.  Hence  to  minimize  recompilat Jons,  it  is  advantageous  to  compile  the  module  body 

and  the  module  specification  (the  visible  part)  in  different  compilations. 
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Compilers  must  preserve  the  same  degree  of  type  safety  for  a program  consisting  of  several  compilation  units 
and  subunits,  as  for  a program  submitted  as  a single  compilation  unit.  Consequently  a library  file  containing 
information  on  the  compilation  units  of  the  program  library  must  be  maintained  by  the  compiler.  This 
information  may  include  symbol  tables  .and  other  information  pertaining  to  the  order  of  previous  compilations. 

A normal  submission  to  the  compiler  consists  of  the  compilation  unit(s)  and  the  library  file.  The  latter  is 
used  for  checks  and  is  updated  as  a consequence  of  the  current  compilation. 

There  should  be  compiler  commands  for  creating  the  program  library  of  a given  program  or  of  a given  family  of 
programs.  These  commands  may  permit  the  reuse  of  units  of  other  program  libraries.  Finally,  there  should  be 
commands  for  interrogating  the  status  of  the  units  of  a program  library.  The  form  of  these  commands  is  not 
specified  by  the  language  definition. 


10.5  Elaboration  of  Compilation  Units 
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Before  the  execution  of  a main  program,  all  library  modules  that  are  not  subunits  and  that  are  us^d  by  the 
main  program  are  elaborated.  These  modules  are  units  mentioned  in  the  visibility  li3ts  of  the  main  program 
and  of  its  subunits,  end  transitively  in  the  visibility  lists  of  these  library  modules  themselves. 

The  elaboration  of  these  modules  is  performed  consistently  with  the  partial  ordering  defined  by  the  visibility 
1 ists  (see  10.3). 


10.6  Program  Optimization 

A static  expression  can  be  evaluated  by  the  compiler.  In  consequence,  if  a static  expression  is  required  and 
the  actual  expression  involves  a variable,  or  if  an  exception  arises  in  the  evaluation  of  the  expression,  then 
the  program  is  in  error.  On  the  other  hand,  a compiler  may  be  able  to  optimize  a program  by  evaluating 
expressions  which  are  not  required  to  be  static.  If  the  evaluation  raises  an  exception,  then  the  code  in  thrt 
path  in  the  program  can  be  replaced  by  code  to  raise  the  exception.  Under  such  circumstances,  the  compiler 
may  warn  the  programmer  of  a potential  error. 

Optimization  of  the  elaboration  of  declarations  and  the  execution  of  statements  may  be  performed  by  compilers. 
If  a subprogram  is  compiled  by  an  in-line  substitution  of  the  body,  then  expressions  within  the  body  may  bo 
capable  of  further  optimization  as  above. 

A compiler  may  find  that  some  statements  or  subprograms  cannot  be  executed,  in  which  case  the  corresponding 
code  can  be  omitted.  If  non-static  expressions  within  such  code  would  generate  an  exception,  then  the  program 
is  not  in  error.  These  rule3  permit  the  effect  of  corn!  it  tonal  compilation  within  the  language. 
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11.  Exceptions 


This  chapter  defines  the  facilities  for  dealing  with  errors  or  other  exceptional  situations  that  arise  during 
program  execution.  An  except  ion  is  an  event  that  causes  suspension  of  normal  program  execution.  Bringing  an 
exception  to  attention  is  called  raising  the  exception.  To  execute  some  actions,  in  response  to  the  occurrence 
of  an  exception,  is  called  handling  the  exception. 

The  units  whose  execution  can  be  prematurely  terminated  by  an  exception  are  blocks,  subprograms,  and  modules. 
Exceptions  are  introduced  by  exception  declarations.  Exceptions  can  be  raised  explicitly  by  raise  statements, 
or  they  can  be  propagated  by  subprograms,  blocks,  or  language  defined  operations  that  raise  the  exceptions. 
When  an  exception  occurs,  control  can  be  passed  to  a user-provided  exception  handler. 

11.1  Exception  Declarations 


An  exception  declaration  defines  one  or  several  exceptions  whose  names  can  appear  in  raise  statements  and 
exception  handlers  within  the  scope  of  the  declaration. 

Syntax : 

except ion_declarat ion  identif ier_ list  : exception* 

Abstract  Syntax? 

decl  ->  NATURE- DESIGNATOR  S DESCRIPTION 
NATURE 


in 


: : ■ constant 

pcckcne 

DESCRIPTION  : instantiation  I object 


I entry  I exception  I function 

I procedure  I subtype  | task 
renamlr 


I ±n  I in  out  1 out  I 
aHle 


I 


ing  I type  desc 


I tyoe  I var \r 
r iption  I uni t I voi j 


The  identity  of  the  exception  introduced  by  an  exception  declaration  is  established  at  compilation  time 
(exceptions  can  be  viewed  as  constants  of  some  predefined  enumeration  type  initialized  with  static 
expressions).  Hence  an  exception  declaration  introduces  only  one  exception  even  if  it  is  declared  in  a 
recursive  procedure. 

The  following  exceptions  are  predefined  in  the  language: 

ACCESS  ERROR 


ASSERTJ2RR0R 
DISCRIMINANT  ERROR 


When  an  access  variable  has  the  value  null  and  an  attempt  is  made  to  read  or  to 
update  the  designated  dynamic  object  (see  3.8). 

When  violating  an  assertion  (see  5.9). 

When  attempting  to  access  a component  of  a variant  part  not  prescribed  by  the 
record's  discriminant  (see  4.1.2). 
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. DIVIDE_ERROR 

when  dividing  a number  by  zero  (see  4.5.5,  4.5.6). 

n 

PATLURE 

For  general  use  within  procedures  and  tasks.  This  ic  the  only  exception  that 
raised  by  a task  for  another  task  (see  11.3,  11.5). 

can 

be 

f 

o 

INDEX_ERPOR 

When  an  index  value  is  outside  the  range  specified  for  the  array  (see  4.1.1). 

r> 

INITI ATE— ERROR 

when  attempting  to  initiate  a task  that  is  already  active  (see  9.3). 

i 

O 

o 

NO  VALUE  ERROR 

when  accessing  the  value  of  an  uninitialized  variable  or  returning  from  a 

function 

without  a value  (see  6.5). 

o 

OVERFLOW 

When  an  arithmetic  operation  fails  by  attempting  to  produce  a value  which 
large  to  be  handled  by  the  implementation  (see  4.5). 

is 

too 

o 

o 

OVERLAP_ERROR 

When  attempting  to  assign  overlapping  slices  (see  5.1.1). 

o 

o 

RANGE_ERROR 

when  exceeding  the  declared  range  of  a variable  or  typo  (see  4.5). 

o 

SELECT^EPROR 

When  all  alternatives  of  a select  statement  without  else  part  are  closed  (see 

9.7) 

o 

STORAGE  OVERFLOW 

When  the  dynamic  storage  allocated  to  a task  is  exceeded,  or  during  the  execution 

of 

o 

an  allocator,  if  the  available  space  for  the  collection  of  dynamic  objects 

is 

o 

exhausted  (sec  13.2). 

o 

TASKING_ERROR 

When  exceptions  arise  during  intertask  communication  (see  9.2,  11.4). 

o 

UNDERFLOW 

When  a floating  point  operation  fails  by  attempting  to  produce  a value  which 
small  to  be  handled  by  the  implementation  (see  4.5.5). 

is 

too 

o 

o 

o 

o 

11.2  Exception  Handlers 
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1 

o 

The  processing  of  one  or 

more  exceptions  is  specified  by  an  exception  handler.  A handler  may  appear  at 

the 

end 

o ! 

of  a unit  which  must  be  , 

a block,  subprogram  body,  or  module  body.  The  word  unit  will  have  this  meaning 

in 

1 

o 

this  section. 

o i 

Syntax! 

1 

o 

exception  handler  r s > 

B 

O 1 

when  exception  choice  {1  exception  choice)  •> 

o 

sequence^ o f_ statements 

exception_choice  :t« 

exception  name  1 others 

u 

Abstract  Syntax: 

alternative  -> 

CHOICE  S STM  S — I when  CHOICE  S »>  STM  S ) 

choice  s -> 

choice  .. . — [ choice  i . . : i 

stm  s -> 

5TTT 

— i sw:..  1 

I 

J 


am 


! O 

I 

O 

I 


CHOICE  S t !•  choice  s 

CHOICE  I :*  EXP  I other?  I PANCE 

£r’  stm  s 

Deter  lot Ion : 

Each  handler  handles  the  named  exceptions  when  they  are  raised  in  the  given  unit.  An  alternative  containing 
the  choice  others  applies  to  all  exceptions  not  listed  in  other  alternatives,  including  exceptions  whose  names 
arc  not  visible  within  the  current  unit. 

When  an  exception  is  raised  within  a unit,  cither  during  elaboration  of  its  local  declarations,  or  during  the 
execution  of  its  segucnce  of  statements,  the  execution  of  the  corresponding  handler  replaces  the  execution  of 
the  remainder  of  the  unit:  the  actions  following  the  point  where  the  exception  is  raised  are  shipped,  and  the 
execution  of  the  handler  terminates  the  execution  of  the  unit.  If  no  handler  is  provided  for  the  exception, 
the  unit  is  terminated  and  the  exception  is  propag'ted  according  to  the  rules  stated  in  section  11.3.1. 

Since  a handler  acts  rs  a substitute  for  the  corresponding  unit.,  the  handler  has,  in  general,  the  same 
capabilities  as  the  unit  it  replaces.  For  example,  a handler  within  a function  has  access  to  its  parameters 
and  may  issue  a return  statement  on  behalf  of  the  function.  However,  since  an  exception  may  be  raised  during 
the  elaboration  of  the  declarations  local  to  the  unit  considered,  it  cannot  be  assumed  within  a handler  that 
all  declarations  have  been  elaborated. 

Static  semantics: 

procedure  CHECK  HANDLER ( al terna t tve:  TREE:  env:  S ENV)  return  TREE  Is 
cnv2:  S_ENV  T*  INJiAHDLER (env) : 

begin  . - 

return  MAKE  la 1 ternat Ive.  CHFCK  EX  CHOICE  s ( al  tarnat i ve) , env2)  , 

CHECK~ST”_S(ST!i“S(  alternative)  , env2)i  ; 

end; 

procedure  CHECK_EX_CIIOTCE_S  (cholce_s:  TREE;  env:  R_fNV)  return  TREE  is 
begin 

if  IS_EMPTT (choice_s)  then  return  void ; 
else  ~ 

return  PRE(CHECK  EX  CHOICE  (HSAD(cho)ce  s) , env), 

CHECK_EX~CHOICE  S (TAIL (choi ce~s) , env)): 

end  If; 

end  CHECK_EX_CtIOlCE_S; 

procedure  C«ECK_rx_CHOICE (choice:  TREE;  nnv:  <=  f’V)  return  TREE  Is 
begin 

if  IS  NAME (X IMP (choice) ) then 

return  CHECK_EX_NA?’E(choice,  env): 
elslf  choice  « others  then 
return  choice; 

else  return  EXCEPTION  CHOICE  MUST  T A wr, 

end  if; 

end  CHECK_EX_O:.0ICE; 

procedure  CHECK  ex  same (name:  TREE;  env:  S EVV)  return  TPEE  is 
begin 

It  KINO(namc)  • selected  and  IS  TASK (OEN  OF (name (name) , env))  thsn 
return  CHECK  ex  TA.<K(name,  env) : 

else 
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return  TD_PART (DEN_OF ( name , env) ) ; 
end  ifj 

end  CHECK  EX  NAME; 


11.3  Raise  Statements 

An  exception  can  be  explicitly  rained  by  a raise  statement. 

Syntax! 

rnlsc_statemont  :t-  raise  (exception  name] i 
Abstract  Syntax: 

raise  ->  NAVE  VO TO  [raise  NAME_VOIO  I 
NAME  VOTE  !!•  NAME  | void 
Description! 

A raise  statement  raises  the  named  exceptioo.  A task  can  raise  the  predefined  exception  FAILURE  in  another 
task  (say  T)  by  giving  T. FAILURE  as  exception  name.  A raise  statement  of  the  form 

raise; 

can  only  appear  in  a handler.  It  reraises  the  same  exception  which  caused  transfer  to  the  handler. 

Stat i c Semantics: 

procedure  CHECK_RAISE (raise : TREE;  env:  S CUV)  return  TREE  is 
begin 

case  KI«D(NAME_VOTO(ralse)l  of 
when  void  — [ raise;  I 

if  IS_IN_HAHDLER(env)  then 
return  raise; 

else  return  RAISE  ALONE  CAN  ONLY  APPEAR  IN  A HANDLER; 
end  if; 

when  others  •>  — [raise  NAME;  1 

return  MAKE (raise.  CHECK_EX_NAME(NAME_VOID(reise) , env)); 
end  case; 
end  CHECK_RAISE; 

11.3.1  Dynamic  Association  of  Handlers  with  Exceptions 

When  an  exception  is  raised,  normal  program  execution  is  suspended  and  one  of  the  following  events  takes 
place. 

(a)  If  a block  does  not  contain  a local  handler  for  the  exception,  execution  of  the  block  is  terminated  end 
the  same  exception  is  reraised  in  the  enclosing  ?rnu"tct  of  statements.  Similarly,  if  a subprogram  does 
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not  contain  a local  handler,  itn  execution  in  terminated  and  the  exception  is  rereir.cd  at  the  point  of 

cell  of  the  subprogram.  In  both  cases  the  exception  is  said  to  be  propeg ned . The  predefined  exceptions 

arc  exceptions  that  can  be  propagated  by  the  language  defined  constructs. 

(b)  If  a task  does  not  contain  a local  handler  for  the  exception  the  task  is  terminated  but  the  exception  is 
not  propagated. 

(c)  If  a local  handler  has  been  provided,  execution  of  the  handler  replaces  execution  of  the  remainder  of  the 
current  unit.  A further  exception  raised  in  the  sequence  of  statements  of  the  handler  causes  termination 
of  the  current  unit,  and  the  exception  is  propagated  if  tho  currenr  unit  is  a block  or  subprogram  as  in 
case  (a). 

11.4  Exceptions  Raised  during  Tasking 

An  exception  can  be  propagated  to  a task  communicating,  or  attempting  to  communicate,  with  another  task. 

On  any  attempt  to  call  an  entry  or  a subprogram  of  an  inactive  task,  the  TASKING_ERROR  exception  is  raised  in 

the  invoking  task.  Note  that  this  also  applies  to  entry  calls  to  an  active  task  if  the  task  terminates  before 

accepting  these  calls. 

A rendezvous  can  be  terminated  abnormally  ip. three  cases. 

(a)  When  an  exception  is  raised  inside  an  accept  statement  and  not  handled  locally.  in  this  c esc,  the 
exception  is  propagated  both  in  the  unit  containing  tho  accept  statement  and  in  th«  calling  trek  at  the 
point  of  the  entry  call.  (A  different  treatment  is  employed  for  the  exception  FAILURE  as  explained  in 
section  11.5  below. ) 

(b)  When  the  unit  containing  the  accept  statement  is  terminated  abnormally  (c.g.  as  the  result  of  rn  abort 
statement).  In  this  case,  the  TASKING_ERRCR  exception  is  raised  in  the  calling  task  ?t  the  point  of  the 
entry  call. 

(c)  When  the  unit  issuing  the  entry  call  is  terminated  abnormally.  In  this  case  the  rendezvous  terminates 
abnormally  and  the  TASKING_FRROR  exception  is  raised  within  the  called  task,  ih  the  unit  containing  the 
accept  statement. 

A task  calling  a procedure  of  another  task  receives  a TAGKING_ERROR  exception  if  the  called  task  terminates. 

before  the  end  of  the  procedure  execution. 


11.5  Raising  an  Exception  in  Another  Task 
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A task  can  raise  the  predefined  exception  FAILURE  In  another  task  (say  T)  by  a raise  stateircnt  of  tho  fore: 
raise  T. FAILURE: 

The  execution  of  this  statement  has  no  direct  effect  on  the  task  issuing  the  statement  (unless,  of  course,  It 
raises  FAILURE  for  itself). 
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If  the  task  receiving  the  FATLUFE  exception  in  currently  executing,  or  if  it  is  suspended  by  rn  accept  or 
select  statement,  the  effect  1?  to  raisn  the  exception  at  t h ^ point  of  the  current  statement.  Tf  the  task  in 
suspended  on  a delay  statement,  the  cor  r f'spop'l  i nq  wait  in  cancelled  and  the  exception  is  raise, 1 the  point 
of  the  delay  statement.  If  the  tank  her  issued  an  entry  ^ a 1 1 , the  exception  \%  vised  at  the  point  of  the 
call  and  two  cases  are  possible  for  the  colled  task: 

(a)  If  the  entry  call  has  not  yet  been  accepted,  the  call  is  cancelled  and  the  called  task  is  unaffected. 

(b)  Tf  on  accept  statement  for  this  entry  is  in  execution,  the  rendezvous  is  abnormally  terminated  and  the 
TASKING^ ER POP  exception  is  raised,  as  in  section  11.4(c). 

If  a FATLUPE  exception  is  received  by  a susoended  task,  execution  of  the  t^sk  is  scheduled  according  to  the 
priority  rules  (see  9 . e ) in  order  to  allow  handling  of  the  excection.  If  the  exception  FATLUFE  is  received 
within  an  accept  statement  and  not  handled  locally,  the  rendezvous  is  terminated  and  the  exception 
TASKING_FRR0R  is  rained  in  the  calling  task  at  the  point  of  the  entry  call. 

The  predefined  exception  FATLUFE  is  the  only  exception  that  c-~n  be  explicitly  raised  in  another  task.  It 
supersedes  all  other  exceptions  not  yet  handled  or  received  before  FATLUPE  is  handled.  A unit  can  contain  a 
handler  for  the  exception  FAILURE  as  for  any  other  exception. 


11.6  uppressing  Exceptions 


The  detection  of  exception  conditions  may  be  suppressed  within  a unit  by  a pragma  of  the  forms 
pragma  SUPPRESS (exception  n*mc  {#  exception  name}) 

This  pragma  indicates  that  no  run  time  checks  need  be  provided  to  ensure  that  the  named  exceptions  do  not 
arise.  Thn  occurrence  of  such  a pragma  within  a given  unit  does  not  guarantee  that  the  named  exceptions  will 
not  arise  since  the  pragma  is  merely  a recommendation  to  the  compiler,  and  since  the  exceptions  may  be 
propagated  by  called  units.  Should  an  exception  situation  occur  when  the  corresponding  run  time  checks  are 
omitted,  the  program  would  be  erroneous,  and  the  results  unpredictable. 
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A.  APPENOIX:  ABSTRACT  SYNTAX  OF  GREEN 


package  GREEN  SYNTAX  it 
type  CC?;STPUCT  la  ( 


— nullary 


and 

entry 

u 

in  op 

mult 

nuTT 

r '•'1  number 

, end  then 

> 22 
, at 

, tnt  number 

, catenate 
, rxcect  j on 
, ic« 

, Tc 

, constant 
, excon^n*- i at  ion 

TT 

, d iv 

, function 
, in  out 

, mod 
, others 
, p*ckinq 

, restricted  private 

, no 
, or 
, plus 

, s'-n^rate 

, not 
, or  else 
, p r f V a 1 0 
, stub 

, not  in 
, out 

, procedure 
, serine 

Gubt.  voo 

, t -sk 

, lypc 

, variable 

, void 

--  unary 
abort 

ar.n'  r t 

, across 

, Code 

, address 
, delay 

, cn 
, derived 

, allocator 
* got  o 

initiate 
wb  i 1 e 

, raise 
, integer 

, return 

t 

, subunit 

, tyro  description 

— binary 
alternative 
cond  1 1 1 ona.l 

TToTF 

in  TUsoc 

, array 
, constrained 
, for 
, TFTexcd 

, assign 
, exit 
» generic 
, Tn  our  assoc 

, cal  ] 

, TaTTly 
, is  assoc 
, instantiation 

, case 
, fixed 

- U — 

, labeled 

loop 

restricted 

, module 
, p r c'?  a f i ned 
, select 

, ouTTTfied 

, select'd 

, Ob7-Ct 
, renaming 
, selectee  strino 

, out  assoc 
, reverse 
, slice 

cubcroqrom 

variant 

, ty->ci  cMr 
, variant  part 

, unary 

9 

, unit 

, U£a 

— ternary 

accept 

dec) 

, binary 
, tr c mbar ship 

. block 
, record  repr 

, comp  repr 

9 

, condition 

— arbitrary 
alternative  s 

, bounds  s 

, choice  $ 

COfiJp  G 

, co no  assoc  s 

, com c r?cr  s 

conditional  s 

, 3ccl  G 

, dcsiqnator  s 

cun  s 

, Item  s 

, name  s 

par am  assoc  s 

, range  s 

, ver  1 ant  s 

) 

type  ARITTES  is  (nullary,  unary,  binary,  ternary,  arbitrary) i 
function  ARITY  (construct:  CONSTRUCT)  return  f ptttfs; 
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type  SORT  Is  3Ct_of  (CONSTRUCT) ; 

--  Wo  assume  a generic  package  set  has  been  defined 
— which  provides  sets  end  union  of  sets 

— Table  of  all  sorts 


ALTERNATIVE 

OOUNPS  S 
COUP  Asgoc 

ALTERNATIVE  S 
fllf-ICE 

COMP  TFPR 

BINARY  OP 
CNOlfE  A 

COMR  RE PR  S 

, BODY 
, COM° 

, CON 0 

POUNDS  , 

CO"P  s 

• 

COSO  VOID 

CONDITION  OP 

CONDITIONAL 

, (‘•ommjtTONAL 

S 

/ 

cti‘‘-t«M  sr 

fo-'CTRAj-iro 

retT 

, PFCL  S 

DFCL  PART, 

nrccFthTlCN 

PE ~ T ON AT OR 

DESIGNATOR  S 

, EX» 

rXP  VOTD  , 

f'XT  ’Iv.ic 

?*.v.:p»i<?  ASsoc 

ID 

, 7d"votp 

TTFM  # ITEM  S 

ITrR^TION 

mf:?,'cr  op 

VANS 

# VAMF  C 

t.’,V!E  VOTD, 

NATURE 

p»ip 

PAPAS  ASSOC 

, pa RAM  ASEOC 

s 

‘StTALIFieO, 

RAV?,F 

RANGE  VOTD 

RESULT 

, F°r.C T FT  EF 

GTH  , 

ST  ’ S 

STRING 

TYPE 

, TYPF  RANGE 

TYPE  SPEC, 

imW  op 

VARIANT 

VARIANT  S 

: constant  SORT; 

function  SORT_OF_SON (construct : CONSTRUCT;  n:  T NT EG PR  :•  0)  return  SORT; 

— the  expTcssion  SORT_OF_ SON (construct , njdcnotos  the  sort  of  the 

— n-th  argument  of  "construct",  if  it  is  of  fixed  arity.  In  the  case 

— of  a list  construct,  it  denotes  the  common  sort  of  each  son. 


private 

— The  sorts  are  initialised  so  as  to  be  the  sets  described  by  the  following  table: 

— ALTERNATIVE  alternative 

— ALTERNATIVE  S : : * alternative  8 

I exponentiation  I £e  I 
I mult  I mod  I 


I selected  I 


— BINARY  OP  ; 

: : ■ and 

catena  te 

1 div 

eo 

— 

31 

To 

i rr 

minus 

— BODY  j 

ne 

i : * block 

not 

stub 

1 or 

1 void 

plus 

EXT  NAME 

— BOUNDS  ; 

: _id 

Indexed 

1 pair 

prc3ef  t ned 

••  t yoed  pr  i r 

--  POUNDS  S bounds  s 


O i 

I 

1 

o 

o 

o 

o 

o 

I 

o 
o 
o 
o ! 


O I 


- - 

CHOICE  : 

■ 

EXP  1 others  1 

RANGE 

— 

CHOICE  S : 

m 

choice  s 

-- 

COMP 

m 

dec! 

1 null 

-- 

CP”P 

S ; 

m 

comp  s 

— 

COMP 

ASSOC  : 

m 

name  3 

1 all 

-- 

float  number 

1 TT- 

— 

nul  1 

1 predefined 

— 

selected  strlnq 

1 slice 

-- 

COMP 

PEPR  : 

m 

corro  rerr 

-- 

COMP 

PE  PR  S 

:*  comp  rerr  a 

-- 

CCND 

:*  cone  it  ion  1 

EXP 

— 

COND 

VOID 

:•  C owd  I void 

-- 

condition  op 

:■  and  then!  or 

else 

— 

CONDITIONAL 

:•  conTTTTon  sT” 

variant  part 

»1 locator  I binary  I call  I comp  assoc  s 

int  number  I indexed  I membership  j 

on: 1 i fi re  i real  number  I selected  1 

str i no  I unary 


O I 


Formal  Definition 


H - 2 


Prel imlnary  Draft 


a . 

_ _ 

CONDITIONAL  S 

s:*  conditional  s 

-- 

CONSTRAINT 

fixed 

r 

float  1 como  assoc  s 1 oair 

i 

-- 

tyoed 

P»ir  | 

ranoe  s 1 void 

r- 

-- 

CONSTRAINED 

j : • const rn inod 

1 

o 

— 

DFCL 

DECL  S 

: ■ d-^cl 
:*  c’cc  l s 

j 

C i 

— 

DECL  PART 

: ■ use 

1 item  s 

i 

o 

-- 

description 

: * i nr tent iat ion 

1 object  I renami 

ng  I tyoe  dec 

criotion  1 

° i 

un  i t 

1 void 

— 

designator 

: » id 

1 string 

l 

DPS  T GNA  J'OR  S 

: » '..es  ignator  s 



F.XP 

all 

1 allocator 

I binary 

I call  1 comp  assoc  s 1 

O 



float 

member 

number 
r,h  i o 

1 id 

1 null 

| int  number 

1 predefined 

1 indexed  I 

1 curl i f ied  1 

° ! 

— 

reel  number 

1 selected 

I slice 

— 

str ing 

1 unary 

o 

— 

EXP  VOID 

exp 

I voi  r) 

! 

— 

EXT  NAME 

NAVE 

1 selected  string 

1 string 

o 

— 

GENERIC  ASSOC 

PA PAM 

ASSOC 

1 selected  string 

1 is  assoc 

o ( 

i 

O 

„ 

in  : • ■ 

id 

• • 

° i 

— 

in  VOID  : 

Td 

1 void 

— 

ITEM 

address 

1 decl 

1 comp  rcor  1 

packing  1 

record  repr  1 

o • 

vJ 

-- 

restricted 

1 subunit  1 RXP 

— 

7 TEW  .9 

i tew  s 

) 

o 

— 

TTE PATTON 

for 

1 rev" 

rse  1 void  1 

while 

-- 

KFM-CR  OP 

i n op 

1 not 

In 

^ i 

— 

NAVE  ... 

1 1 

I kT- 

1 indexed  1 

predefined  I 

selected  1 slice 

i 

o 

-- 

NAVE  S 

name  s 

o j 

— 

NAME  VOID  :•« 

1 void 

-- 

NATURE 

constant 

1 entr 

y f exception  } 

function  | 

o 

— 

in 

1 in  out  1 out  1 

package  j 

procedure  1 subtype  1 

O ) 

— 

task 

1 type 

1 variable 

o 

— 

PAIR 

PAR AM  ASSOC 

: : ■ pair 

: t - in  assoc  1 in 

out  assoc  1 out 

assoc  1 EXP 

o 

-- 

PARAM  ASSOC  S 

: : ■ oar  am 

assoc  s 

o 

— 

QUALIFIED 

: : * oual i f i ed 

° 1 

O 

— 

RANGE  : : 

■ pair 

1 typed  pair 

— - 

RANGE  VOID  t: 

- void  I RANGE 

'*■*  L 

— 

RESULT  : • 

* constrained  ( void 

SPCCtFICR 

?TM 


STM  S 
STRING 


f ■**  Ti  1 1 y 
accept 
cod  ? 


I ZTT 

label od  | looc 

Stm  s 

string 


I generic  I module  I subprogram  I void 

I abort  I assign!  assort  ! block  ' cal  1 I case 

I rx*t  I goto 

I nu^  I 


I TT  | ini t jatc  I 

I return  I select 
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— TYPE 

s : * recess 

1 arr»y 

coup  s 

constrained  I 

— 

derived 

I c’oslqnator  s 

r ixM 

float  1 

-- 

integer 

1 private 

restricted  private 

voi<2 

r* 

— TYPE  RANGE 

: :*  cone  trained 

1 R31  r 

typed  pair 

— TYPE  SPEC 

suboroqrr.n 

1 voTtT  ( TYPE 

0 

t 

— UNARY  CP  : 

» .finus  1 not  | 

plus 

o 

1 

o 

— VARIANT 

— VARTAN?  S 

: ■ v & r i r n t 
:■  vari-rn*  s 

o 

i 

■ o 

i 

o 

j ° 

o 

I ° 

o 

i 
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o 
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j o 

o 

i 

J O 

j 

o 

i o 

o 

! o 

i 

o 

o 

f 

o 

jo 

o 

1 o 

<_ 

1 o 

I ° 

! O ♦ 

< 

; D 

i 

! o 

: o 

i 

i 

i O 

i o 

I 

| o 
I o 

I 

i 

! o 

I 

i 

i ° 

I o 

I 

! o 

! 

o 

I 

i ° 

i 

I O 

o 

o 


--  The  constructs  of  Green  have  a structure  described 
— by  the  following  tables: 

--  Unary  constructs 


abort 

-> 

NAM*  S 
f-itt  ■ 

access 

-> 

ao cress 

-> 

rxp 

?1 1 

-> 

n-'mf 

rT 1 ocator 

-> 

QUALIFIED 

error t 

-> 

CO  vo 

cod  * 

-> 

QUALIFIED 

?TT7v 

-> 

EXP 

cl  c r i /cd 

-> 

rO"^TP.MNED 

^e  to 

-> 

ID 

initiate 

-> 

NAME  S 

integer 

-> 

RANGE 

r r ir.o 

-> 

NAME  VOID 

return 

-> 

EXP  VOTD 

subunit 

-> 

er.CL 

tyce  descriotion 

-> 

TYPE 

will  J e 

-> 

F.XP 

--  Binary  constructs 


— 

al  ter  native 

->  CHOICE  S 

STM  S 

-- 

•array 

->  BOUNDS  S 

TYPE 

— 

assign 

->  NAME 

EXP 

-- 

c.?!l 

->  NAME 

PAP, AM  ASSOC 

S 

— 

case 

->  EXP 

ALTERNATIVE 

S 

-- 

corrli  tional 

->  COND 

STM  S 

-- 

const ra  ined 

->  NAME 

CONSTRAINT 

-- 

exit 

->  TO  VOID 

COMD  VOID 

— 

TS?7ly 

->  HANGS 

r.periPTER 

-- 

fixed" 

->  TfyP 

pV’Or  VOTD 



f lo-t 

->  rxp 

RAMOF  VOTD 

— 

for 

->  ID 

R^NSE 

- - 

aensric 

->  DrCL  S 

CPFCTFIER 

— 

■ft 

->  co'idttionm. 

S STM  S 

— 

Tn  assoc 

->  in 

exp 

-- 

indexed 

->  NAME 

FX*  S 

in  out  assoc 

->  in 

FVP 

— 

insfntiat  ion 

->  MTME 

P-APAM  ASSOC 

S 

-- 

is  assoc 

> DESIGNATOR 

F XT  NAME 

— 

labeled 

->  ID 

STM 

— 

3 OOP 

->  ITERATION 

gTM  S 

— oui  ~3SOC 

— pa  i r 

--  c.rcc'cf  i ned 
--  c 1 j a 1 1 f j^d 

— r?nr,n  j no  ~ 

— reverse 
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rcstr ictrtf 

-> 

WSMP  S 

DECT,  S 

.. 

c^l "rt 

-> 

C" JHITIOMAL  S 

pt”  71 

_ _ 

s'Toctcrf 

-> 

!!,V«F 

10 

r* 

-- 

1 rcted  strinq 

-> 

v'.'*E 

STRING 

— 

rlic? 

-> 

W *V*1E 

PM30E 

-- 

subrroqrru 

-> 

PECL  S 

RESULT 

r*  i 

— 

tyn->  pelf 

-> 

•VY12 

PMR 

' i 

— 

u n •»  r ^ 

-> 

11M\WY  OP 

rxp 

— 

un  1 "t 

-> 

FPKCTFTEP 

'V'OY 

C 

-- 

USC 

-> 

M*MJ' 

TTrr  s 

-- 

v * r i .**  n t 

-> 

c«nTcr  r> 

CO.iP  S 

-- 

vcri**nt  port 

-> 

W'F. 

VM-  T A\’T  S 

o 

__ 

Torncry  constructs 

o 

.. 

rccrot 

-> 

WV1E 

DSCL  S 

STM  S 

- - 

Pinery 

-> 

?XP“ 

nr' ary  op 

EXP 

o 

-- 

block" 

-> 

DP?L  PAPT 

LTETWATTVE  S 

— 

comp  roor 

-> 

fj(V«F 

ryp 

H A.VGE 

• - 

ronel t ion 

-> 

rvo 

CO'-T  TTfO\»  OP 

CO*’D 

o 

— 

3 eel 

-> 

tTvruRE 

errroy^TOP  $ 

nfsfRTPTION 

— 

meTbershio 

-> 

p VP 

t-*Fv,p*EF  OP 

TYPF 

— 

rocor  rrpr 

-> 

HWF 

EXP 

COMP  FEPR  S 

o 

— 

List  constructs 



alternative  s 

-> 

MyiTTWrTVE 

o 

-- 

bounce  f 

-> 

•>  "•lll'.pq 

— 

ol-ioic'-'  s 

-> 

c-^ice 

o 

— 

roiv.c  s 

-> 

f n ’P 

-r 

coif,  assoc  s 

-> 

\*$oc 

— 

comp  rrr  r 

-> 

.p  F’Fpr 

o 

— 

conOitionrl • s 

-> 

C''!OTTTr'',*L 

-- 

•i?c3  s’  ’ ' 

-> 

OrTL 

-- 

■*>p. i in :tor  s 

-> 

pc~,  TO*'?*Tr'9 

o 

— 

CX  0 3 

-> 

r-<p 

— 

it  err  n 

-> 

?rrv 

— 

nr  me  s 

-> 

”'"r 

o 

-- 

p.  r'.T  essoc  s 

-> 

I’  ‘ !<  A*1 

— 

r e r i : n 

-> 

• -\V.-p 

— 

v r i •*'  n t s 

-> 

v ’ r i ~ mt 

u 

I 


end  OPFFv  SYNTAX) 


O 


For xi.?)  Definition 


A 


Preliminary  Draft 


J. 


o 


o 


« 

i o 
i o 


I o 


j 

o 


I 


o 

o 


package  GREEN  TREES  is 
use  green_Syntax? 
type  TPEE~is  private) 

— Tree  constructors 


procedure 

procedure 

procedure 

procedure 


procedure 

procedure 

procedure 


procedure 

procedure 

procedure 

procedure 

procedure 


MAKE (construct  s 

CONSTRUCT? 

8 S 

STRTNG) 

return 

TFEF? 

MAKE (construct  s 

COfT.TRUCT? 

t ? 

TREE) 

return 

TppE  ? 

MAKE (construct : 

OO'-’OTPUCT  J 

1 1 , 

, 1 2 : TREE) 

return 

Tppc. 

MAKE (construct : 

C'VMTIHJCI  I 

M 

, t?,  t 1 : TREE) 

return 

TREE? 

— Tree  selectors 


KIND  (ts  TREE)  return  CONSTRUCT? 

SON  (n:  INTEGER,  t:  TREE)  return  TPEF?  . 

TOKEN  (ts  TTTE)  return  STRING? 

--  Handling  of  list  constructs 

HEAD  (Is  TREE)  return  TREE? 

TAIL  (It  TREE)  return  TREE? 

PRE  (ts  TFEE , Is  TREE)  return  TREE? 

EMPTY  (construct:  CONSTRUCT)  return  TFFC  ? 

IS  EMPTY (1:  TPFF)  return  BOOLEAN? 


private 

— Description  of  the  implementation  of  type  TREE 
end  GREEN_TPEES? 
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package  GREEN  SELECTORS  is 

uae  OREEN_?YNTAX,  GREEM  TREES) 

--  To  inc7oa.se  readabilTty,  one  wishes  to  ovoid  positional  selection  of  subtrees. 

— To  this  effect,  selector  functions  are  defined  that  are  named  after  the  sort 
--  of  the  corresponding  subtree. 

— Example:  if:  constant  TPEE  --  wh«re  XIHD(if)  - j_f 

— then  SOM  ( 1 , if)  is  equivalent  to  CO!’DTTTON_S  ( if ) and 

--  SO!l ( 2 , if)  is  equivalent  to  STH_S(if)~ 

— Hence  the  following  selectors  are  declared: 
procedure  CONDITIO'!  R(t:  TREE)  return  TREE? 
procedure  STM_S(t:  TREE)  return  TREE; 

— and  so  on  for  each  construct  of  fixed  arity.  In  cases  like  pair 
--  which  has  more  than  one  son  of  the  same  sort,  numbering  is  used; 

procedure  EXPlft:  TPEE)  return  TREr t 
procedure  EXP2(t:  tree)  return  TREE; 
end  GREEN  SELECTORS; 
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